Menu
▾
▴
lush-devel — Lush-devel: Discussing Lush development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(13) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(5) |
Feb
(13) |
Mar
(1) |
Apr
(3) |
May
(1) |
Jun
(2) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2004 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(6) |
May
(3) |
Jun
|
Jul
|
Aug
(7) |
Sep
(8) |
Oct
|
Nov
(2) |
Dec
|
| 2005 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
(18) |
May
|
Jun
(16) |
Jul
(13) |
Aug
(48) |
Sep
|
Oct
(9) |
Nov
(29) |
Dec
(16) |
| 2006 |
Jan
(15) |
Feb
(70) |
Mar
(56) |
Apr
(28) |
May
(20) |
Jun
(15) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(3) |
Nov
(5) |
Dec
(2) |
| 2007 |
Jan
(4) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
(7) |
Nov
|
Dec
(3) |
| 2008 |
Jan
(10) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(4) |
Aug
(1) |
Sep
(10) |
Oct
(15) |
Nov
(2) |
Dec
(5) |
| 2009 |
Jan
(2) |
Feb
(1) |
Mar
(9) |
Apr
|
May
(4) |
Jun
(3) |
Jul
(12) |
Aug
(3) |
Sep
(15) |
Oct
(14) |
Nov
(11) |
Dec
(7) |
| 2010 |
Jan
(3) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(12) |
| 2011 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Yann L. <ya...@cs...> - 2009-10-19 14:29:20
|
Raymond, We actually got persmission from all the people we could think of. We think a lot more people would use Lush in industrial contexts if we switched to the LGPL. We knew you contributed to the documentation, which is really not affected by the license, but I guess we overlooked your contributions to the code. Would you give your permission for the switch, as far as your contributions are concerned? If not, we will just take out your contributions, but that would be a shame. Thanks, -- Yann On Monday 19 October 2009, Raymond Martin wrote: > On October 19, 2009 01:14:37 am Ralf Juengling wrote: > > Folks, a first Lush 2.0 beta release is out. > > Download: https://sourceforge.net/projects/lush/files > > Yeah, how did this end up under LGPL? > > If any of the previous GPL code from older Lush has been used then you > cannot change it to LGPL unless you get permission from everybody who > contributed code to those parts. I contributed a small little bit, plus > some documentation and was never asked about this and did not see anything > on the lists, IIRC. > > I remember in the past asking about certain licenses and such and being > told by Leon that it would be almost impossible to contact people that > had contributed. So on that basis, it looks like this is a license > violation, not to mention a violation of the copyrights of all those > contributors. > > And, in fact, I see from the COPYRIGHT file and the headers in all the C > files that this is definitely a license violation. There was never a LGPL 2 > as stated in those. The Lesser LGPL started at version 2.1. Seems you have > just added the word "Lesser" in place. > > This immediately invalidates any license claim and means you must cease > distribution of this package until this situation is rectified (revert back > to GPL). > > Raymond > > --------------------------------------------------------------------------- >--- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is > the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Lush-devel mailing list > Lus...@li... > https://lists.sourceforge.net/lists/listinfo/lush-devel |
|
From: Raymond M. <la...@gm...> - 2009-10-19 14:16:21
|
On October 19, 2009 01:14:37 am Ralf Juengling wrote: > Folks, a first Lush 2.0 beta release is out. > Download: https://sourceforge.net/projects/lush/files Yeah, how did this end up under LGPL? If any of the previous GPL code from older Lush has been used then you cannot change it to LGPL unless you get permission from everybody who contributed code to those parts. I contributed a small little bit, plus some documentation and was never asked about this and did not see anything on the lists, IIRC. I remember in the past asking about certain licenses and such and being told by Leon that it would be almost impossible to contact people that had contributed. So on that basis, it looks like this is a license violation, not to mention a violation of the copyrights of all those contributors. And, in fact, I see from the COPYRIGHT file and the headers in all the C files that this is definitely a license violation. There was never a LGPL 2 as stated in those. The Lesser LGPL started at version 2.1. Seems you have just added the word "Lesser" in place. This immediately invalidates any license claim and means you must cease distribution of this package until this situation is rectified (revert back to GPL). Raymond |
|
From: Aleksej S. <as...@in...> - 2009-10-19 07:30:16
|
Ralf Juengling <jue...@cs...> writes: > Folks, a first Lush 2.0 beta release is out. fpu.c:42:18: error: fenv.h: No such file or directory fpu.c:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'standard_fenv' fpu.c: In function 'ywith_fpu_env': fpu.c:143: error: 'fenv_t' undeclared (first use in this function) fpu.c:143: error: (Each undeclared identifier is reported only once fpu.c:143: error: for each function it appears in.) fpu.c:143: error: expected ';' before 'current_fenv' fpu.c:145: warning: implicit declaration of function 'fegetenv' fpu.c:145: error: 'saved_fenv' undeclared (first use in this function) fpu.c:147: error: 'standard_fenv' undeclared (first use in this function) fpu.c:152: warning: implicit declaration of function 'fesetenv' fpu.c: In function 'parse_excepts': fpu.c:175: error: 'FE_INVALID' undeclared (first use in this function) fpu.c:179: error: 'FE_DIVBYZERO' undeclared (first use in this function) fpu.c:183: error: 'FE_OVERFLOW' undeclared (first use in this function) fpu.c:187: error: 'FE_UNDERFLOW' undeclared (first use in this function) fpu.c:191: error: 'FE_INEXACT' undeclared (first use in this function) fpu.c:195: error: 'FE_ALL_EXCEPT' undeclared (first use in this function) fpu.c: In function 'unparse_excepts': fpu.c:209: error: 'FE_INEXACT' undeclared (first use in this function) fpu.c:212: error: 'FE_UNDERFLOW' undeclared (first use in this function) fpu.c:215: error: 'FE_OVERFLOW' undeclared (first use in this function) fpu.c:218: error: 'FE_DIVBYZERO' undeclared (first use in this function) fpu.c:221: error: 'FE_INVALID' undeclared (first use in this function) fpu.c: In function 'xfpu_test': fpu.c:291: warning: implicit declaration of function 'fetestexcept' fpu.c: In function 'xfpu_clear': fpu.c:299: warning: implicit declaration of function 'feclearexcept' fpu.c: In function 'xfpu_round': fpu.c:359: error: 'FE_TOWARDZERO' undeclared (first use in this function) fpu.c:363: error: 'FE_TONEAREST' undeclared (first use in this function) fpu.c:367: error: 'FE_UPWARD' undeclared (first use in this function) fpu.c:371: error: 'FE_DOWNWARD' undeclared (first use in this function) fpu.c:378: warning: implicit declaration of function 'fesetround' fpu.c: In function 'sprint_excepts': fpu.c:389: error: 'FE_DIVBYZERO' undeclared (first use in this function) fpu.c:392: error: 'FE_INVALID' undeclared (first use in this function) fpu.c:395: error: 'FE_INEXACT' undeclared (first use in this function) fpu.c:398: error: 'FE_OVERFLOW' undeclared (first use in this function) fpu.c:401: error: 'FE_UNDERFLOW' undeclared (first use in this function) fpu.c: In function 'xfpu_info': fpu.c:449: warning: implicit declaration of function 'fegetround' fpu.c:450: error: 'FE_TOWARDZERO' undeclared (first use in this function) fpu.c:451: error: 'FE_TONEAREST' undeclared (first use in this function) fpu.c:452: error: 'FE_UPWARD' undeclared (first use in this function) fpu.c:453: error: 'FE_DOWNWARD' undeclared (first use in this function) fpu.c:460: error: 'FE_ALL_EXCEPT' undeclared (first use in this function) fpu.c: In function 'fpu_reset': fpu.c:484: error: 'standard_fenv' undeclared (first use in this function) fpu.c: In function 'init_nan': fpu.c:500: error: 'FE_DFL_ENV' undeclared (first use in this function) fpu.c:501: error: 'FE_ALL_EXCEPT' undeclared (first use in this function) fpu.c:503: error: 'FE_OVERFLOW' undeclared (first use in this function) fpu.c:504: error: 'standard_fenv' undeclared (first use in this function) gmake[1]: *** [fpu.o] Error 1 uname -mrs NetBSD 5.99.20 i386 grep -rF FE_DIVBYZERO /usr/include /usr/include/x86/ieeefp.h:#define FE_DIVBYZERO 0x04 /* divide-by-zero exception */ /usr/include/x86/ieeefp.h:#define FP_X_DZ FE_DIVBYZERO /* divide-by-zero exception */ -- HE CE3OH... |
|
From: Ralf J. <jue...@cs...> - 2009-10-19 05:14:57
|
Folks, a first Lush 2.0 beta release is out. Download: https://sourceforge.net/projects/lush/files Many changes have been made since the last Lush 1.x release that will facilitate future development. But there are also a number of visible changes and Lush 2.0 is not fully backward compatible. The differences include: - Lush 2.x is case-sensitive - outdated packages have been dropped (HTK, Torch, and others) - many functions have been renamed (see namespace lush1-) Some things are currently broken, including - the make-standalone facility - some outdated packages (video4linux, sn28, and others) - support for complex numbers New features include - builtin math functions work on arrays - a namespace facility - a small datatype library (heap, sets, graph) - a gnuplot interface Have fun, Ralf |
|
From: Ralf J. <jue...@cs...> - 2009-09-30 23:18:34
|
I just stumbled across the bug exhibited by the code
below. Strange that this has gone undetected for so long.
Ralf
(defclass C object
((-int-) count) )
(defmethod C C (i)
(declare (-int-) i)
(setq count i)
())
(defmethod C incr ()
(incr count)
(incr count)
())
(defmethod C do ()
(let ((count0 count))
(declare (-int-) count0)
(==> this incr)
(printf "%d\n" (- count count0)) )
())
(let ((obj (new C 1)))
(==> obj do) )
(dhc-make ()
(C C incr do)
)
(let ((obj (new C 1)))
(==> obj do) )
|
|
From: Ralf J. <jue...@cs...> - 2009-09-28 16:04:48
|
Ok, I set up a MediaWiki for us. The url is https://sourceforge.net/apps/mediawiki/lush/index.php?title=Main_Page I believe anybody may create and edit pages right now. Ralf On Sat, 26 Sep 2009, Yann LeCun wrote: > Let's keep it simple and use mediawiki hosted on SF then. > > -- Yann > > On Friday 25 September 2009, Ralf Juengling wrote: >> I don't really have a preference for any particular wiki. >> What seems important is that we choose a host service >> that is not tied to anyone's current affiliation and could >> get lost some day. Do you know a trustworthy free hosting >> service? >> >> Sourceforge is offering MediaWiki, by the way. >> >> ralf >> >> On Fri, 25 Sep 2009, Yann LeCun wrote: >>> That sounds great. I vote for a wiki. I suggest >>> dokuwiki, which requires no database. >>> >>> -- Yann >>> >>> On Friday 25 September 2009, Ralf Juengling wrote: >>>> The Lush homepage hasn't been touched in a long time, >>>> which might mislead people into thinking nothing is >>>> happening with Lush anymore. >>>> >>>> We do not have a home for howtos, code samples, >>>> installation instructions, and other things that users >>>> might want to contribute. >>>> >>>> One idea would be to do what some other projects do >>>> and have the homepage be a wiki. This could serve >>>> both purposes as users would be able to add pages >>>> and edit content (with a few exceptions like the front >>>> page, perhaps). >>>> >>>> Does that sound good? Other ideas? >>>> >>>> Ralf > > |
|
From: Yann L. <ya...@cs...> - 2009-09-26 16:27:24
|
Let's keep it simple and use mediawiki hosted on SF then. -- Yann On Friday 25 September 2009, Ralf Juengling wrote: > I don't really have a preference for any particular wiki. > What seems important is that we choose a host service > that is not tied to anyone's current affiliation and could > get lost some day. Do you know a trustworthy free hosting > service? > > Sourceforge is offering MediaWiki, by the way. > > ralf > > On Fri, 25 Sep 2009, Yann LeCun wrote: > > That sounds great. I vote for a wiki. I suggest > > dokuwiki, which requires no database. > > > > -- Yann > > > > On Friday 25 September 2009, Ralf Juengling wrote: > >> The Lush homepage hasn't been touched in a long time, > >> which might mislead people into thinking nothing is > >> happening with Lush anymore. > >> > >> We do not have a home for howtos, code samples, > >> installation instructions, and other things that users > >> might want to contribute. > >> > >> One idea would be to do what some other projects do > >> and have the homepage be a wiki. This could serve > >> both purposes as users would be able to add pages > >> and edit content (with a few exceptions like the front > >> page, perhaps). > >> > >> Does that sound good? Other ideas? > >> > >> Ralf |
|
From: Ralf J. <jue...@cs...> - 2009-09-26 03:46:30
|
I don't really have a preference for any particular wiki. What seems important is that we choose a host service that is not tied to anyone's current affiliation and could get lost some day. Do you know a trustworthy free hosting service? Sourceforge is offering MediaWiki, by the way. ralf On Fri, 25 Sep 2009, Yann LeCun wrote: > That sounds great. I vote for a wiki. I suggest > dokuwiki, which requires no database. > > -- Yann > > On Friday 25 September 2009, Ralf Juengling wrote: >> The Lush homepage hasn't been touched in a long time, >> which might mislead people into thinking nothing is >> happening with Lush anymore. >> >> We do not have a home for howtos, code samples, >> installation instructions, and other things that users >> might want to contribute. >> >> One idea would be to do what some other projects do >> and have the homepage be a wiki. This could serve >> both purposes as users would be able to add pages >> and edit content (with a few exceptions like the front >> page, perhaps). >> >> Does that sound good? Other ideas? >> >> Ralf >> >> >> --------------------------------------------------------------------------- >> --- Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Lush-devel mailing list >> Lus...@li... >> https://lists.sourceforge.net/lists/listinfo/lush-devel > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Lush-devel mailing list > Lus...@li... > https://lists.sourceforge.net/lists/listinfo/lush-devel > |
|
From: Yann L. <ya...@cs...> - 2009-09-25 22:48:52
|
That sounds great. I vote for a wiki. I suggest dokuwiki, which requires no database. -- Yann On Friday 25 September 2009, Ralf Juengling wrote: > The Lush homepage hasn't been touched in a long time, > which might mislead people into thinking nothing is > happening with Lush anymore. > > We do not have a home for howtos, code samples, > installation instructions, and other things that users > might want to contribute. > > One idea would be to do what some other projects do > and have the homepage be a wiki. This could serve > both purposes as users would be able to add pages > and edit content (with a few exceptions like the front > page, perhaps). > > Does that sound good? Other ideas? > > Ralf > > > --------------------------------------------------------------------------- >--- Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Lush-devel mailing list > Lus...@li... > https://lists.sourceforge.net/lists/listinfo/lush-devel |
|
From: Ralf J. <jue...@cs...> - 2009-09-25 19:01:23
|
The Lush homepage hasn't been touched in a long time, which might mislead people into thinking nothing is happening with Lush anymore. We do not have a home for howtos, code samples, installation instructions, and other things that users might want to contribute. One idea would be to do what some other projects do and have the homepage be a wiki. This could serve both purposes as users would be able to add pages and edit content (with a few exceptions like the front page, perhaps). Does that sound good? Other ideas? Ralf |
|
From: Ralf J. <jue...@cs...> - 2009-09-16 16:07:25
|
Hm, then it's probably easier to go with the second option, where you would substitute -gblearn- by -float-: ? (defnamespace gblearn- '((-gbtype- -float-))) = gblearn- ? (in-namespace* gblearn- (de f (y) (declare (-gbtype-) y) (1+ y)) ) = (f) ? ^Pf (lambda (y) (declare (-float-) y) (1+ y) ) = t It looks like -gbtype- is only used in two files, so only the definitions in those two would need to be wrapped in '(in-namespace* gblearn- ..)'. Ralf On Wed, 16 Sep 2009, Yury Sulsky wrote: > Ralf, > > I'm having a bit of trouble with this. I'm trying to get a simple > example to work, something like this: > > (in-namespace* lush1- (defvar -gbtype- -flt-)) > (de f (y) (declare (-gbtype-) y) (1+ y)) > > It looks like one of the changes between Lush 1 and Lush 2 is the use > of symbol properties for type names. So while lush1 uses (eval > :-gbtype-), lush2 uses (getp '-gbtype- 'type-syntax). > > Adding this: > > (putp '-gbtype- 'type-syntax (getp '-flt- 'type-syntax)) > (putp '-gbtype- 'srg-type (getp '-flt- 'srg-type)) > > fixes it in the interpreter, but I still get a compile error (with > both dhc-make and dhc-make-sf): > > *** compiler : Unrecognized type specifier : (-gbtype-) > *** in: (declare (-gbtype-) y) > *** from: (lambda (y) (declare (-gbtype-) y) (1+ y)) > > Yury > > On Tue, Sep 15, 2009 at 11:10 PM, Ralf Juengling <jue...@cs...> wrote: >> >> I just looked at gblearn2 myself. It's probably easiest to start >> out by replacing all dhc-make by dhc-make-sf, which means you >> compile in the lush1- namespace. >> >> Another issue I saw is the use of idx-m2resize (defined in >> libidx/idx-macros). I believe this used to be a type-generic >> macro for resizing a matrix. There are similar but >> type-specific macros defined in the same file. idx-m2resize >> now is also type-specific and is for resizing mptr-matrices >> (it was the logical name for it). Now you need to look what >> type-specific macro is required in place of idx-m2resize >> (e.g., idx-f2resize for float matrices). >> >> >> >> On Tue, 15 Sep 2009, Ralf Juengling wrote: >> >>> Hi Yuri, >>> >>> The names -float- etc. were bound to some black-magic >>> macros. These macros are still there but are defined >>> in the namespace lush1- for backwards compatibility. >>> >>> You have two options, you could either do >>> >>> (in-namespace* lush1- >>> >>> (defvar -gbtype- -float-) >>> ... >>> >>> ) ; in-namespace* >>> >>> to bind the alternative names -gbtype- etc. to the old macros. >>> >>> Or you could do it the way it is done in the opengl-interface, >>> that is, define a new namespace for the gblearn code to do >>> the translations "-gptype- -> -float-" etc. In the end you >>> do the compilation in the namespace lush1-. Take a look at the >>> file packages/opengl/opengl.lsh. >>> >>> Ralf >>> >>> >>> >>> On Tue, 15 Sep 2009, Yury Sulsky wrote: >>> >>>> Hi Ralf, >>>> >>>> I'm taking a look at the gblearn2 package, but I'm not sure how to >>>> translate >>>> one piece of code to Lush2. >>>> >>>> The code defines a type: >>>> (defvar -gbtype- -float-) >>>> >>>> This doesn't work anymore. Are types kept in a different namespace? >>>> >>>> Thanks, >>>> Yury >>>> >>>> On Sep 15, 2009, at 11:30 AM, Ralf Juengling <jue...@cs...> wrote: >>>> >>>>> Folks, >>>>> >>>>> I was thinking about releasing a lush2 beta before >>>>> releasing a final and now I think it's a good idea. >>>>> I will announce the beta on freshmeat and hope to get >>>>> a few more people interested in lush that way. If lush >>>>> is to have a future, we need to work on building a >>>>> community. >>>>> >>>>> I plan to do the release in a month from now, October >>>>> 15. There are still a couple of things on our todo list, >>>>> https://sourceforge.net/apps/trac/lush/wiki/LushTwoTodoList, >>>>> mostly package updates. But the documentation and our >>>>> homepage also need to be looked at. I do not plan to do >>>>> all of these myself and ask that some folks on this list >>>>> pick up one or the other work item. Packages that are not >>>>> fixed by October 15 will not be included in the beta >>>>> distribution. >>>>> >>>>> Ralf >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>>>> is the only developer event you need to attend this year. Jumpstart your >>>>> developing skills, take BlackBerry mobile applications to market and >>>>> stay >>>>> ahead of the curve. Join us from November 9-12, 2009. Register >>>>> now! >>>>> http://p.sf.net/sfu/devconf >>>>> _______________________________________________ >>>>> Lush-devel mailing list >>>>> Lus...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/lush-devel >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9-12, 2009. Register >>> now! >>> http://p.sf.net/sfu/devconf >>> _______________________________________________ >>> Lush-devel mailing list >>> Lus...@li... >>> https://lists.sourceforge.net/lists/listinfo/lush-devel >>> >> > |
|
From: Ralf J. <jue...@cs...> - 2009-09-16 03:11:02
|
I just looked at gblearn2 myself. It's probably easiest to start out by replacing all dhc-make by dhc-make-sf, which means you compile in the lush1- namespace. Another issue I saw is the use of idx-m2resize (defined in libidx/idx-macros). I believe this used to be a type-generic macro for resizing a matrix. There are similar but type-specific macros defined in the same file. idx-m2resize now is also type-specific and is for resizing mptr-matrices (it was the logical name for it). Now you need to look what type-specific macro is required in place of idx-m2resize (e.g., idx-f2resize for float matrices). On Tue, 15 Sep 2009, Ralf Juengling wrote: > Hi Yuri, > > The names -float- etc. were bound to some black-magic > macros. These macros are still there but are defined > in the namespace lush1- for backwards compatibility. > > You have two options, you could either do > > (in-namespace* lush1- > > (defvar -gbtype- -float-) > ... > > ) ; in-namespace* > > to bind the alternative names -gbtype- etc. to the old macros. > > Or you could do it the way it is done in the opengl-interface, > that is, define a new namespace for the gblearn code to do > the translations "-gptype- -> -float-" etc. In the end you > do the compilation in the namespace lush1-. Take a look at the > file packages/opengl/opengl.lsh. > > Ralf > > > > On Tue, 15 Sep 2009, Yury Sulsky wrote: > >> Hi Ralf, >> >> I'm taking a look at the gblearn2 package, but I'm not sure how to translate >> one piece of code to Lush2. >> >> The code defines a type: >> (defvar -gbtype- -float-) >> >> This doesn't work anymore. Are types kept in a different namespace? >> >> Thanks, >> Yury >> >> On Sep 15, 2009, at 11:30 AM, Ralf Juengling <jue...@cs...> wrote: >> >>> Folks, >>> >>> I was thinking about releasing a lush2 beta before >>> releasing a final and now I think it's a good idea. >>> I will announce the beta on freshmeat and hope to get >>> a few more people interested in lush that way. If lush >>> is to have a future, we need to work on building a >>> community. >>> >>> I plan to do the release in a month from now, October >>> 15. There are still a couple of things on our todo list, >>> https://sourceforge.net/apps/trac/lush/wiki/LushTwoTodoList, >>> mostly package updates. But the documentation and our >>> homepage also need to be looked at. I do not plan to do >>> all of these myself and ask that some folks on this list >>> pick up one or the other work item. Packages that are not >>> fixed by October 15 will not be included in the beta >>> distribution. >>> >>> Ralf >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9-12, 2009. Register now! >>> http://p.sf.net/sfu/devconf >>> _______________________________________________ >>> Lush-devel mailing list >>> Lus...@li... >>> https://lists.sourceforge.net/lists/listinfo/lush-devel >> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Lush-devel mailing list > Lus...@li... > https://lists.sourceforge.net/lists/listinfo/lush-devel > |
|
From: Ralf J. <jue...@cs...> - 2009-09-16 02:26:22
|
Yuri, I also wanted to ask you about the profiler. I tried to use it a while ago and one interesting function was recursive. The timing results were non-sensical. I was wondering if something broke with all the changes from lush1 to lush2, or if it never worked for recursive functions? Thanks, Ralf |
|
From: Ralf J. <jue...@cs...> - 2009-09-16 02:23:07
|
Hi Yuri, The names -float- etc. were bound to some black-magic macros. These macros are still there but are defined in the namespace lush1- for backwards compatibility. You have two options, you could either do (in-namespace* lush1- (defvar -gbtype- -float-) ... ) ; in-namespace* to bind the alternative names -gbtype- etc. to the old macros. Or you could do it the way it is done in the opengl-interface, that is, define a new namespace for the gblearn code to do the translations "-gptype- -> -float-" etc. In the end you do the compilation in the namespace lush1-. Take a look at the file packages/opengl/opengl.lsh. Ralf On Tue, 15 Sep 2009, Yury Sulsky wrote: > Hi Ralf, > > I'm taking a look at the gblearn2 package, but I'm not sure how to translate > one piece of code to Lush2. > > The code defines a type: > (defvar -gbtype- -float-) > > This doesn't work anymore. Are types kept in a different namespace? > > Thanks, > Yury > > On Sep 15, 2009, at 11:30 AM, Ralf Juengling <jue...@cs...> wrote: > >> Folks, >> >> I was thinking about releasing a lush2 beta before >> releasing a final and now I think it's a good idea. >> I will announce the beta on freshmeat and hope to get >> a few more people interested in lush that way. If lush >> is to have a future, we need to work on building a >> community. >> >> I plan to do the release in a month from now, October >> 15. There are still a couple of things on our todo list, >> https://sourceforge.net/apps/trac/lush/wiki/LushTwoTodoList, >> mostly package updates. But the documentation and our >> homepage also need to be looked at. I do not plan to do >> all of these myself and ask that some folks on this list >> pick up one or the other work item. Packages that are not >> fixed by October 15 will not be included in the beta >> distribution. >> >> Ralf >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Lush-devel mailing list >> Lus...@li... >> https://lists.sourceforge.net/lists/listinfo/lush-devel > |
|
From: Ralf J. <jue...@cs...> - 2009-09-15 15:31:10
|
Folks, I was thinking about releasing a lush2 beta before releasing a final and now I think it's a good idea. I will announce the beta on freshmeat and hope to get a few more people interested in lush that way. If lush is to have a future, we need to work on building a community. I plan to do the release in a month from now, October 15. There are still a couple of things on our todo list, https://sourceforge.net/apps/trac/lush/wiki/LushTwoTodoList, mostly package updates. But the documentation and our homepage also need to be looked at. I do not plan to do all of these myself and ask that some folks on this list pick up one or the other work item. Packages that are not fixed by October 15 will not be included in the beta distribution. Ralf |
|
From: Ralf J. <jue...@cs...> - 2009-09-10 23:19:37
|
FYI, this change is now implemented. Note that Yann's version of test0 and the original version of test0 (below) now behave differently (intentionally so). I have attached a little script with examples you may run to see the new behavior. Ralf On Fri, 12 Dec 2008, Yann LeCun wrote: > Even though the behavior of "static" variables is semantically well > defined, it's true that this particular behavior is a bit confusing > (like the behavior of defvar which most people expect to work like > setq or defparameter). > > The semantic of the code below is exactly like: > > (defparameter some_random_name [0 0 0 0 0]) > (defun test0 () > (for (i 0 3) > (let ((v some_random_name)) > (v 0 (+ (v 0) 1)) > (printf "%f " (v 0)) )) > (print) ) > > The proper way to fix this is to make array literal create a new > matrix every time, and return it. > > -- Yann > > > On Friday 12 December 2008, Ralf Juengling wrote: >> Hello, >> >> Consider this code, which exhibits a malicious bug. >> >> (defun test0 () >> (for (i 0 3) >> (let ((v [0 0 0 0 0])) >> (v 0 (+ (v 0) 1)) >> (printf "%f " (v 0)) )) >> (print) ) >> >> ? (test0) >> 1 2 3 4 >> = () >> >> The desired output is "1 1 1 1". If I remember correctly, >> somewhere in the documentation array literals are advertised >> as a means to simulate something like "static variables" in >> C. But here it does not square with the semantics of let. >> >> In my opinion, this is behavior will be confusing to many >> users and we should change it in Lush2. When compiled, v >> should simply be allocated on the stack when it is not returned >> (and dynamically otherwise). >> >> Ralf >> >> --------------------------------------------------------------------------- >> --- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, >> Nevada. The future of the web can't happen without you. Join us at MIX09 >> to help pave the way to the Next Web now. Learn more and register at >> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com >> / _______________________________________________ >> Lush-devel mailing list >> Lus...@li... >> https://lists.sourceforge.net/lists/listinfo/lush-devel > > > > |
|
From: Ralf J. <jue...@cs...> - 2009-09-02 23:14:11
|
On Wed, 2 Sep 2009, Yann LeCun wrote: > The mmap functionality was implemented to allow access to > large data files without having to explicitely load them > into RAM in advance. Back in the old days of Solaris, if > you mmapped in read-only mode, the swapping system was > smart enough to never swap out. Hence you would save > a lot on disk (or network) bandwidth. > > Also, you really don't want a random bug in a Lush program > to inadvertently corrupt your dataset file on disk...... > > That said, we could have two types of mmapped storages: > one for read only, and one for read/write. That sounds like Solaris' swapping was a actually not very smart if it swapped out untouched, writable pages. Ok, I will look into it. Ralf |
|
From: Yann L. <ya...@cs...> - 2009-09-02 22:19:29
|
The mmap functionality was implemented to allow access to large data files without having to explicitely load them into RAM in advance. Back in the old days of Solaris, if you mmapped in read-only mode, the swapping system was smart enough to never swap out. Hence you would save a lot on disk (or network) bandwidth. Also, you really don't want a random bug in a Lush program to inadvertently corrupt your dataset file on disk...... That said, we could have two types of mmapped storages: one for read only, and one for read/write. -- Yann Leon might remember. I seem to rememberthink writing to mmapped storages used to crash on Solaris On Wednesday 02 September 2009, Ralf Juengling wrote: > Hi, > > Does anyone remember why lush does not allow to > manipulate memory mapped storages? > > Ralf > > > --------------------------------------------------------------------------- >--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day trial. Simplify your report design, integration and deployment - and > focus on what you do best, core application coding. Discover what's new > with Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Lush-devel mailing list > Lus...@li... > https://lists.sourceforge.net/lists/listinfo/lush-devel |
|
From: Ralf J. <jue...@cs...> - 2009-09-02 22:12:33
|
Hi, Does anyone remember why lush does not allow to manipulate memory mapped storages? Ralf |
|
From: Ralf J. <jue...@cs...> - 2009-08-31 00:45:32
|
I have reintegrated the code that spawns a child process for the garbage collection. You need to activate it explicitly at configure time, ./configure --with-snapshot-gc If you do not have an issue with lush's responsiveness then there is no reason to activate it. I plan to maintain the garbage collector as an independent project (libcmm.sf.net). Lush should link to the library, starting in some future release, and take advantage of improvements to the collector in this way. A few more comments on the intended use of this feature. This is, strictly speaking, not a solution that uses multi-threading. It uses the fork() system call, which is not available on Windows, for instance. It is also a more heavy-weight operation than starting a thread. For actual realtime applications you would need a realtime OS and response-time guarantees for system calls. I suppose this will work well enough in practice for quasi realtime applications like Yann's robots. But be aware that fork() may fail under heavy system load! You would then see a message from the MM module, mm(collect): could not spawn child for GC: Cannot allocate memory mm(collect): trying synchronous collect Ralf On Sun, 15 Mar 2009, Yann LeCun wrote: > Unfortunately (as you probably suspected), shutting off gc doesn't > solve the problem. > > If a robot runs a sensor-reading/actuator-controlling loop, it will > eventually run out of memory and probably crash unless the gc is > called periodically. While gc runs, the robot runs blinds (or the > game, video, or music stops in a multimedia app). > > One possibility is to systematically call the gc at the end of the loop, > but the question is: how long does the gc takes to complete, even if > little a small amount of memory was allocated since the last call? > > On the current SVN version of lush2, a simple call to (gc) on a > "blank" interpreter (right after startup) takes about 15ms on my > Core2Duo laptop. That makes the option of calling (gc) all the time > totally impractical. > > If lush2 is to be used for applications where a predictable response > time is required, which includes real-time vision and signal > processing, robotics, games, video and multimedia, it seems to me that > a separate gc thread is the only viable solution. > > That's precisely why Java has a separate thread for gc. > > These applications are very important to many Lush users. > > -- Yann > > > On Sunday 15 March 2009, Ralf Juengling wrote: >> Not sure if it solves the problem, but I added a new >> form 'with-nogc' which temporarily blocks garbage >> collections. Should work when the number of allocations >> in the loop is within reasonable limits. >> >> You can do a similar thing in C (see the implementation >> of with-nogc in toplevel.c). >> >> Ralf >> >> On Wed, 11 Mar 2009, Yann LeCun wrote: >>> One problem with a single thread implementation of >>> course is that it pretty much precludes the use >>> of Lush 2.0 for any semi-real-time application >>> like robotics or games. For these applications >>> you want a repeatable run time for a loop, and >>> can't afford to have the system sit around and do >>> garbage collection once in a while. >>> >>> So, maintaining the option to spawn a separate >>> thread for GC might be a good idea. >>> >>> -- Yann >> >> --------------------------------------------------------------------------- >> --- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Lush-devel mailing list >> Lus...@li... >> https://lists.sourceforge.net/lists/listinfo/lush-devel > > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Lush-devel mailing list > Lus...@li... > https://lists.sourceforge.net/lists/listinfo/lush-devel > |
|
From: Ralf J. <jue...@cs...> - 2009-08-01 15:55:47
|
On Sat, 25 Jul 2009, Ralf Juengling wrote: > [...] > > This long (progn ...)-expression was generated > automatically by code in libc/cparser and copied into > glenums.lsh. Ok. But the definitions in glenums.lsh > could become out of sync with what's actually in the > header file gl.h (in fact, glenum.lsh was incomplete > (and maybe out-of-sync) when I checked a couple days ago). > > What's wrong with extracting the constants from gl.h & co > on the spot, when glenums.lsh is loaded? I made this change in the update of the opengl interface I submitted yesterday. glenum.lsh now reads like this: (libload "libc/cparse") (libload "opengl/opengl-config") (eval (cparse-extract-constants opengl-gl-h)) (eval (cparse-extract-constants opengl-glext-h)) (eval (cparse-extract-constants opengl-glu-h)) Let me know if you find there's a problem with loading glenum.lsh or with missing constants. If this works well, then we I think we should do more of this. There are other situations where you wish lush could parse C or C++ code to help you with creating interfaces. We should look into using one of the open C/C++ parsers (like Elsa, clang, or Sparse). That would be a really cool project... if someone here is looking for something to work on. ;) ralf |
|
From: Ralf J. <jue...@cs...> - 2009-08-01 01:52:23
|
On Fri, 31 Jul 2009, Yann LeCun wrote: > Leon introduced the constants mechanism to avoid crowding the > namespace, because constants extracted from a C header may > clash uncontrolably with existing symbols. > > Also, @ and @@ are different. @@ evaluates at read time (like #.) > whereas @ evaluates at compile time. It's not entirely clear that > we absolutely need both, but they are different. I think we don't need either read macro anymore. The compiler, when encountering a symbol that has not been declared as a local variable or function argument, looks for global definitions. When the symbol is globally bound, it will be evaluated at compile time and the value taken as a constant. (If you had not used defconstant to declare the global variable, you will be warned by the compiler.) This is basically the former behavior that of '@xyz'. For read-time evaluation there is #. . There currently is no read-macro for compile-time evaluation of forms in lush2 (what you could do with '@(foo ...)' before). But I have only seen very few uses of this. And in all cases I have seen foo was some kind of constant arithmetic expression. One might as well leave it to the C-compiler to optimize. As for name clashes, that is good point. But name clashes are not a problem specific to compilation, or to importing names from headers. It's a more general problem and the namespace facility in lush2 is a general solution. To avoid name clashes you would place all constant definitions in a project-specific namespace and do the compilation in that namespace. So, updating the code in files that currently do (libload "libc/constants") typically mounts to removing all occurrencs of '@' and updating the defconstant declarations. I finally updated the opengl interface today, if you want to see an example. Cheers, Ralf > > -- Yann > > > On Friday 31 July 2009, Ralf Juengling wrote: >> Some definitions in libc.lsh might be problematic because >> memory management had changed (malloc & free), and most >> others were redundant. @ and @@ as they were defined in >> libc/constants was unecessary, I thought (why limit your >> namespace, especially if there are better ways ?). >> For both situations there are alternatives--just use >> defconstant and #. for read-time evaluation, as in >> common lisp. >> >> I removed those files so that it is clear which files I >> still need to update and what to look for. >> >> Ralf >> >> On Fri, 31 Jul 2009, Yann LeCun wrote: >>> Hi Ralf, >>> >>> Any good reason for not removing libc.lsh and constants.lsh >>> from Lush2 in lsh/libc? >>> >>> SDL and a whole bunch of other packages use them. >>> >>> Is there another to do the same thing on Lush2? >>> >>> -- Yann >>> >>> >>> >>> ------------------------------------------------------------------------- >>> ----- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day trial. Simplify your report design, integration and deployment - >>> and focus on what you do best, core application coding. Discover what's >>> new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Lush-devel mailing list >>> Lus...@li... >>> https://lists.sourceforge.net/lists/listinfo/lush-devel > > > |
|
From: Yann L. <ya...@cs...> - 2009-07-31 18:35:35
|
> On Fri, 31 Jul 2009, Yann LeCun wrote: > > This functionality is still needed, even with the new > > memory management scheme. > > > > For example, if you want to allocate a C struct inside of a Lush > > object, the memory management will be handled by the > > constructor/destructor of the Lush object which will need to call > > malloc and free. > > Right, I agree. And those uses case would not be > problem. Problems would occur when you were trying > to assemble a lush object, or parts of it, using > malloc and expect the runtime/interpreter will accept > it as one of its own. I hope such uses are rare or > absent in legacy code. I can't think of any legacy code that uses that, because I don't think that would have worked in Lush1 either. > I just resurrected libc. Cool. -- Yann > > On Friday 31 July 2009, Ralf Juengling wrote: > >> On Fri, 31 Jul 2009, Yann LeCun wrote: > >>> malloc anf free in libc.lsh were meant to call the > >>> C malloc() and free(), without memory management. > >> > >> Right. > >> > >>> A *lot* of libraries use them. > >>> I'm not sure what the alternative is in Lush2. > >> > >> If you need a managed buffer and don't want to compile > >> you would do > >> > >> (let ((buf (char-array <bufsize>))) > >> .. > >> (foo (idx-base buf)) > >> .. > >> ) > >> > >> to create the buffer and get the address. > >> > >> In compiled code you alternatively may use inline > >> C and mm_blob() if you know what you are doing. > >> Here is documentation for lush's memory manager: > >> http://sourceforge.net/apps/trac/libcmm/wiki/LibDocu > >> > >> If you need an unmanaged buffer and don't want to > >> compile, then you need indeed something like > >> malloc and free as were defined in libc. In compiled > >> code, just use inline C. > >> > >> If we bring libc back, the code that uses malloc and > >> free might compile just fine but still be broken, > >> depending on what you are doing with the memory. > >> That code should be reviewed. > >> > >> I will respond to the constants issue later, > >> Ralf > >> > >>> -- Yann > >>> > >>> On Friday 31 July 2009, Ralf Juengling wrote: > >>>> Some definitions in libc.lsh might be problematic because > >>>> memory management had changed (malloc & free), and most > >>>> others were redundant. @ and @@ as they were defined in > >>>> libc/constants was unecessary, I thought (why limit your > >>>> namespace, especially if there are better ways ?). > >>>> For both situations there are alternatives--just use > >>>> defconstant and #. for read-time evaluation, as in > >>>> common lisp. > >>>> > >>>> I removed those files so that it is clear which files I > >>>> still need to update and what to look for. > >>>> > >>>> Ralf > >>>> > >>>> On Fri, 31 Jul 2009, Yann LeCun wrote: > >>>>> Hi Ralf, > >>>>> > >>>>> Any good reason for not removing libc.lsh and constants.lsh > >>>>> from Lush2 in lsh/libc? > >>>>> > >>>>> SDL and a whole bunch of other packages use them. > >>>>> > >>>>> Is there another to do the same thing on Lush2? > >>>>> > >>>>> -- Yann > >>>>> > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>>-- -- ----- Let Crystal Reports handle the reporting - Free Crystal > >>>>> Reports 2008 30-Day trial. Simplify your report design, integration > >>>>> and deployment - and focus on what you do best, core application > >>>>> coding. Discover what's new with Crystal Reports now. > >>>>> http://p.sf.net/sfu/bobj-july > >>>>> _______________________________________________ > >>>>> Lush-devel mailing list > >>>>> Lus...@li... > >>>>> https://lists.sourceforge.net/lists/listinfo/lush-devel > >> > >> ------------------------------------------------------------------------ > >>--- --- Let Crystal Reports handle the reporting - Free Crystal Reports > >> 2008 30-Day trial. Simplify your report design, integration and > >> deployment - and focus on what you do best, core application coding. > >> Discover what's new with Crystal Reports now. > >> http://p.sf.net/sfu/bobj-july > >> _______________________________________________ > >> Lush-devel mailing list > >> Lus...@li... > >> https://lists.sourceforge.net/lists/listinfo/lush-devel > > > > ------------------------------------------------------------------------- > >----- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > > 30-Day trial. Simplify your report design, integration and deployment - > > and focus on what you do best, core application coding. Discover what's > > new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Lush-devel mailing list > > Lus...@li... > > https://lists.sourceforge.net/lists/listinfo/lush-devel > > --------------------------------------------------------------------------- >--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day trial. Simplify your report design, integration and deployment - and > focus on what you do best, core application coding. Discover what's new > with Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Lush-devel mailing list > Lus...@li... > https://lists.sourceforge.net/lists/listinfo/lush-devel |
|
From: Ralf J. <jue...@cs...> - 2009-07-31 17:19:13
|
On Fri, 31 Jul 2009, Yann LeCun wrote: > This functionality is still needed, even with the new > memory management scheme. > > For example, if you want to allocate a C struct inside of a Lush > object, the memory management will be handled by the > constructor/destructor of the Lush object which will need to call > malloc and free. Right, I agree. And those uses case would not be problem. Problems would occur when you were trying to assemble a lush object, or parts of it, using malloc and expect the runtime/interpreter will accept it as one of its own. I hope such uses are rare or absent in legacy code. I just resurrected libc. Ralf > > Cheers, > > -- Yann > > > On Friday 31 July 2009, Ralf Juengling wrote: >> On Fri, 31 Jul 2009, Yann LeCun wrote: >>> malloc anf free in libc.lsh were meant to call the >>> C malloc() and free(), without memory management. >> >> Right. >> >>> A *lot* of libraries use them. >>> I'm not sure what the alternative is in Lush2. >> >> If you need a managed buffer and don't want to compile >> you would do >> >> (let ((buf (char-array <bufsize>))) >> .. >> (foo (idx-base buf)) >> .. >> ) >> >> to create the buffer and get the address. >> >> In compiled code you alternatively may use inline >> C and mm_blob() if you know what you are doing. >> Here is documentation for lush's memory manager: >> http://sourceforge.net/apps/trac/libcmm/wiki/LibDocu >> >> If you need an unmanaged buffer and don't want to >> compile, then you need indeed something like >> malloc and free as were defined in libc. In compiled >> code, just use inline C. >> >> If we bring libc back, the code that uses malloc and >> free might compile just fine but still be broken, >> depending on what you are doing with the memory. >> That code should be reviewed. >> >> I will respond to the constants issue later, >> Ralf >> >>> -- Yann >>> >>> On Friday 31 July 2009, Ralf Juengling wrote: >>>> Some definitions in libc.lsh might be problematic because >>>> memory management had changed (malloc & free), and most >>>> others were redundant. @ and @@ as they were defined in >>>> libc/constants was unecessary, I thought (why limit your >>>> namespace, especially if there are better ways ?). >>>> For both situations there are alternatives--just use >>>> defconstant and #. for read-time evaluation, as in >>>> common lisp. >>>> >>>> I removed those files so that it is clear which files I >>>> still need to update and what to look for. >>>> >>>> Ralf >>>> >>>> On Fri, 31 Jul 2009, Yann LeCun wrote: >>>>> Hi Ralf, >>>>> >>>>> Any good reason for not removing libc.lsh and constants.lsh >>>>> from Lush2 in lsh/libc? >>>>> >>>>> SDL and a whole bunch of other packages use them. >>>>> >>>>> Is there another to do the same thing on Lush2? >>>>> >>>>> -- Yann >>>>> >>>>> >>>>> >>>>> ----------------------------------------------------------------------- >>>>> -- ----- Let Crystal Reports handle the reporting - Free Crystal Reports >>>>> 2008 30-Day trial. Simplify your report design, integration and >>>>> deployment - and focus on what you do best, core application coding. >>>>> Discover what's new with Crystal Reports now. >>>>> http://p.sf.net/sfu/bobj-july >>>>> _______________________________________________ >>>>> Lush-devel mailing list >>>>> Lus...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/lush-devel >> >> --------------------------------------------------------------------------- >> --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day trial. Simplify your report design, integration and deployment - and >> focus on what you do best, core application coding. Discover what's new >> with Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Lush-devel mailing list >> Lus...@li... >> https://lists.sourceforge.net/lists/listinfo/lush-devel > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Lush-devel mailing list > Lus...@li... > https://lists.sourceforge.net/lists/listinfo/lush-devel > |
|
From: Yann L. <ya...@cs...> - 2009-07-31 16:54:38
|
In Lush1, you could already create managed memory chunks with:
(let ((buf (ubyte-matrix <bufsize>)))
..
(foo (idx-ptr buf))
..
)
The intended role of malloc and free was for unmanaged
(or self-managed) memory chunks. They were simply provided
as a shorthand for "(to-gptr #{ malloc($n) #})" and
"#{ free($ptr) #}".
This functionality is still needed, even with the new
memory management scheme.
For example, if you want to allocate a C struct inside of a Lush
object, the memory management will be handled by the
constructor/destructor of the Lush object which will need to call
malloc and free.
Cheers,
-- Yann
On Friday 31 July 2009, Ralf Juengling wrote:
> On Fri, 31 Jul 2009, Yann LeCun wrote:
> > malloc anf free in libc.lsh were meant to call the
> > C malloc() and free(), without memory management.
>
> Right.
>
> > A *lot* of libraries use them.
> > I'm not sure what the alternative is in Lush2.
>
> If you need a managed buffer and don't want to compile
> you would do
>
> (let ((buf (char-array <bufsize>)))
> ..
> (foo (idx-base buf))
> ..
> )
>
> to create the buffer and get the address.
>
> In compiled code you alternatively may use inline
> C and mm_blob() if you know what you are doing.
> Here is documentation for lush's memory manager:
> http://sourceforge.net/apps/trac/libcmm/wiki/LibDocu
>
> If you need an unmanaged buffer and don't want to
> compile, then you need indeed something like
> malloc and free as were defined in libc. In compiled
> code, just use inline C.
>
> If we bring libc back, the code that uses malloc and
> free might compile just fine but still be broken,
> depending on what you are doing with the memory.
> That code should be reviewed.
>
> I will respond to the constants issue later,
> Ralf
>
> > -- Yann
> >
> > On Friday 31 July 2009, Ralf Juengling wrote:
> >> Some definitions in libc.lsh might be problematic because
> >> memory management had changed (malloc & free), and most
> >> others were redundant. @ and @@ as they were defined in
> >> libc/constants was unecessary, I thought (why limit your
> >> namespace, especially if there are better ways ?).
> >> For both situations there are alternatives--just use
> >> defconstant and #. for read-time evaluation, as in
> >> common lisp.
> >>
> >> I removed those files so that it is clear which files I
> >> still need to update and what to look for.
> >>
> >> Ralf
> >>
> >> On Fri, 31 Jul 2009, Yann LeCun wrote:
> >>> Hi Ralf,
> >>>
> >>> Any good reason for not removing libc.lsh and constants.lsh
> >>> from Lush2 in lsh/libc?
> >>>
> >>> SDL and a whole bunch of other packages use them.
> >>>
> >>> Is there another to do the same thing on Lush2?
> >>>
> >>> -- Yann
> >>>
> >>>
> >>>
> >>> -----------------------------------------------------------------------
> >>>-- ----- Let Crystal Reports handle the reporting - Free Crystal Reports
> >>> 2008 30-Day trial. Simplify your report design, integration and
> >>> deployment - and focus on what you do best, core application coding.
> >>> Discover what's new with Crystal Reports now.
> >>> http://p.sf.net/sfu/bobj-july
> >>> _______________________________________________
> >>> Lush-devel mailing list
> >>> Lus...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/lush-devel
>
> ---------------------------------------------------------------------------
>--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and deployment - and
> focus on what you do best, core application coding. Discover what's new
> with Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Lush-devel mailing list
> Lus...@li...
> https://lists.sourceforge.net/lists/listinfo/lush-devel
|
30 messages has been excluded from this view by a project administrator.