November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Moose-dev] mooseentitystate

by jannik.laval

self timeStamp ifNotEmpty: [:s | |subS| subS := s subStrings first subS first isLetter ifTrue:[^subS]]. ^'' On Nov 12, 2011, at 22:44 , StÃ©phane Ducasse wrote: > good idea. > if you have a piece of code send it. > > Stef > > On Nov 9, 2011, at 9:32 AM, jannik.laval wrote: > >> Hi Stef, >> >> It is not so simple :) >> Take this example from Moose: >> >> === >> LANNode methodDictionary collect:[:e | e timeStamp ifNotEmpty: [:s | s subStrings first ]] >> === >> >> LANNode has no author, so if you take the first substring you will have the date of creation. >> I have not a good solution, but for my scripts, I test the first character of the substring: if it is a letter, this is an author, else, there is no author. >> === >> ((myString subStrings) first at:1) isLetter >> === >> >> Cheers, >> >> On Nov 6, 2011, at 21:48 , StÃ©phane Ducasse wrote: >> >>> http://code.google.com/p/pharo/issues/detail?id=4971 >>> >>>> >>>>> In moose ? because in pharo this is like that and the changes I added where just to make sure that all the clients do not have to deal with timestamp stupid parsing. >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> --- >> Jannik Laval >> >> > > --- Jannik Laval

Nov. 13, 2011

Re: [Pharo-project] FFI wish list: double arrays and friends

by StÃ©phane Ducasse

we will have some cases don't worry. JNIPort Mars? DBXTalk cairo Stef On Nov 13, 2011, at 7:07 PM, Schwab,Wilhelm K wrote: > Sig, > > The problem is that I can't release the current form for various reasons. My plan is to make (roughly) 2000 methods and 135 structure definitions available, plus any other wrappers that can be separated from the grip of GPL. The tangled BLAS and GSL libraries will necessitate a wrapper library of some type, but the current form needs to go on a proprietary code diet. > > It's a lot of work for one-at-a-time fixes. Callbacks will be a big step in the right direction. It would be nice to get the array types at the same time. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] > Sent: Sunday, November 13, 2011 12:07 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI wish list: double arrays and friends > > On 12 November 2011 18:43, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> Stef is hinting that you are going to have some good news about OpenGL and >> FFI in general. One area in which I have been fumbling along is arrays of >> doubles, float, signed and unsigned single and double words. Some of it is >> redundant and arguably more about making code written for Dolphin happy in >> Pharo, but the doubles really are missing. Alignment is a concern; I have >> been lucky. It would be nice to get it right. >> >> I (ab)use byte arrays to hold the data, have some accessors that I seldom >> use (most of the access is, thankfully for speed, through functions in >> external libraries). Ideally, Pharo would provide a full range of double, >> float, signed and unsigned single and double and probably quad words with >> FFI awareness of all of them. >> > > It is easy to add more types and other stuff, except that i need some > real stuff to work with, like one you working on. > > >> Where is all of this going? >> >> My GSL interface is scarred by the past lack of support for underscores, and >> really needs to be rebuilt now that this is no longer a problem. It's even >> worse with PLplot because their function names are mystifyingly cryptic; >> Camel Case them and they are *completely* unrecognizable :( >> >> Another wrinkle with GSL is that I was unable to load it (as-is) on Linux. >> At least at the time, there were two libraries (GSL itself and BLAS) that >> were inter-dependent. A library that uses both would load, but the >> individual libraries would not open via FFI. I put a bunch of my own code, >> and some proprietary code, into the library that allows the offenders to >> load. With license constraints and the joys of GPL, I need to separate these >> things before a public release. >> >> It would be nice to clean all of this stuff at one shot and get first >> releases of PLplot and GSL bindings for Pharo. Callbacks would provide >> clean use of the minimizers and solvers in GSL, allowing me to remove a lot >> of confusing junk that I added to work around the missing features. It >> should be worth the wait. >> > > Starting from Jan. i will focus on adding missing stuff to > NativeBoost, like callbacks and > code inlining. We can solve these things one by one. > >> Bill >> > > > -- > Best regards, > Igor Stasenko. > >

Nov. 13, 2011

Re: [Pharo-project] FFI wish list: double arrays and friends

by Schwab,Wilhelm K

Sig, The problem is that I can't release the current form for various reasons. My plan is to make (roughly) 2000 methods and 135 structure definitions available, plus any other wrappers that can be separated from the grip of GPL. The tangled BLAS and GSL libraries will necessitate a wrapper library of some type, but the current form needs to go on a proprietary code diet. It's a lot of work for one-at-a-time fixes. Callbacks will be a big step in the right direction. It would be nice to get the array types at the same time. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Sunday, November 13, 2011 12:07 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI wish list: double arrays and friends On 12 November 2011 18:43, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Stef is hinting that you are going to have some good news about OpenGL and > FFI in general. One area in which I have been fumbling along is arrays of > doubles, float, signed and unsigned single and double words. Some of it is > redundant and arguably more about making code written for Dolphin happy in > Pharo, but the doubles really are missing. Alignment is a concern; I have > been lucky. It would be nice to get it right. > > I (ab)use byte arrays to hold the data, have some accessors that I seldom > use (most of the access is, thankfully for speed, through functions in > external libraries). Ideally, Pharo would provide a full range of double, > float, signed and unsigned single and double and probably quad words with > FFI awareness of all of them. > It is easy to add more types and other stuff, except that i need some real stuff to work with, like one you working on. > Where is all of this going? > > My GSL interface is scarred by the past lack of support for underscores, and > really needs to be rebuilt now that this is no longer a problem. It's even > worse with PLplot because their function names are mystifyingly cryptic; > Camel Case them and they are *completely* unrecognizable :( > > Another wrinkle with GSL is that I was unable to load it (as-is) on Linux. > At least at the time, there were two libraries (GSL itself and BLAS) that > were inter-dependent. A library that uses both would load, but the > individual libraries would not open via FFI. I put a bunch of my own code, > and some proprietary code, into the library that allows the offenders to > load. With license constraints and the joys of GPL, I need to separate these > things before a public release. > > It would be nice to clean all of this stuff at one shot and get first > releases of PLplot and GSL bindings for Pharo. Callbacks would provide > clean use of the minimizers and solvers in GSL, allowing me to remove a lot > of confusing junk that I added to work around the missing features. It > should be worth the wait. > Starting from Jan. i will focus on adding missing stuff to NativeBoost, like callbacks and code inlining. We can solve these things one by one. > Bill > -- Best regards, Igor Stasenko.

Nov. 13, 2011

Re: [Pharo-project] Broken #isPrime

by StÃ©phane Ducasse

Thanks dave http://code.google.com/p/pharo/issues/detail?id=4997 Stef On Nov 13, 2011, at 4:58 PM, David T. Lewis wrote: > Hi, > > There seems to be a problem with #isPrime in Pharo 1.4. The following example > runs apparently forever: > > 100000000000000000000000000039 isPrime. > > Unfortunately I used #isPrime to demonstrate multiprocessing with worker > images with RemoteTask. RemoteTask seems to work fine on Pharo, but the > examples run "forever" and thus appear to fail due to the #isPrime problem. > > RemoteTask is described here > <http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-November/162167…> > > > Dave

Nov. 13, 2011

Re: [Pharo-project] FFI wish list: double arrays and friends

by Igor Stasenko

On 12 November 2011 18:43, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Stef is hinting that you are going to have some good news about OpenGL and > FFI in general.Â One area in which I have been fumbling along is arrays of > doubles, float, signed and unsigned single and double words.Â Some of it is > redundant and arguably more about making code written for Dolphin happy in > Pharo, but the doubles really are missing.Â Alignment is a concern; I have > been lucky.Â It would be nice to get it right. > > I (ab)use byte arrays to hold the data, have some accessors that I seldom > use (most of the access is, thankfully for speed, through functions in > external libraries).Â Ideally, Pharo would provide a full range of double, > float, signed and unsigned single and double and probably quad words with > FFI awareness of all of them. > It is easy to add more types and other stuff, except that i need some real stuff to work with, like one you working on. > Where is all of this going? > > My GSL interface is scarred by the past lack of support for underscores, and > really needs to be rebuilt now that this is no longer a problem.Â It's even > worse with PLplot because their function names are mystifyingly cryptic; > Camel Case them and they are *completely* unrecognizable :( > > Another wrinkle with GSL is that I was unable to load it (as-is) on Linux. > At least at the time, there were two libraries (GSL itself and BLAS) that > were inter-dependent.Â Â A library that uses both would load, but the > individual libraries would not open via FFI.Â I put a bunch of my own code, > and some proprietary code, into the library that allows the offenders to > load. With license constraints and the joys of GPL, I need to separate these > things before a public release. > > It would be nice to clean all of this stuff at one shot and get first > releases of PLplot and GSL bindings for Pharo.Â Callbacks would provide > clean use of the minimizers and solvers in GSL, allowing me to remove a lot > of confusing junk that I added to work around the missing features.Â It > should be worth the wait. > Starting from Jan. i will focus on adding missing stuff to NativeBoost, like callbacks and code inlining. We can solve these things one by one. > Bill > -- Best regards, Igor Stasenko.

Nov. 13, 2011

[Pharo-project] Broken #isPrime

by David T. Lewis

Hi, There seems to be a problem with #isPrime in Pharo 1.4. The following example runs apparently forever: 100000000000000000000000000039 isPrime. Unfortunately I used #isPrime to demonstrate multiprocessing with worker images with RemoteTask. RemoteTask seems to work fine on Pharo, but the examples run "forever" and thus appear to fail due to the #isPrime problem. RemoteTask is described here <http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-November/162167…> Dave

Nov. 13, 2011

Re: [Pharo-project] Instantiating from a Symbol

by StÃ©phane Ducasse

But environment is a business of classes and not instances. So environment is a class method and this is normal. And if you need to access from an instance method self class environmentâ¦ makes it. Stef > Stef, > > On 12 Nov 2011, at 23:04, StÃ©phane Ducasse wrote: > >> environment should be used in a method while Smalltalk globals more for scripts. > > Yeah, but Nick's point is that #environment is a class method, not an instance method, and maybe it would be handy on the instance side. > > Sven

Nov. 13, 2011

Re: [Pharo-project] Comparing a package code with current code

by Hernan Wilkinson

yeah... it does not work with this package/image version... maybe something has changed and that is the reason... On Sat, Nov 12, 2011 at 4:36 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > changes button always worked for me. > > On 12 November 2011 01:12, Johannes Rasche <johannesrasche(a)mac.com> wrote: > > what else would be compared ?! > > > > anyway I didn't do that, so I cannot judge > > > > I used merge, but that may be cumbersome > > > > Johannes > > > > Am 12.11.11 00:03, schrieb Hernan Wilkinson: > > > > nop... it does not compare the code from the package and image... > > It think I did this before but I don't find the way now. > > > > On Fri, Nov 11, 2011 at 7:51 PM, Francois Stephany > > <tulipe.moutarde(a)gmail.com> wrote: > >> > >> Hi Hernan, > >> > >> Can't you use the 'Changes' button on the Monticello browser? > >> > >>> How can I see the differences between code that is in a > >>> package and the code in an image? > >> > > > > > > > > -- > > HernÃ¡n Wilkinson > > Agile Software Development, Teaching & Coaching > > Mobile: +54 - 911 - 4470 - 7207 > > email: hernan.wilkinson(a)10Pines.com > > site: http://www.10Pines.com > > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina > > > > > > -- > > Johannes Rasche Hagelberger Str. 56 10965 Berlin mail > johannesrasche(a)mac.com > > mobile +49 1577 175 04 75 > > > > -- > Best regards, > Igor Stasenko. > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Nov. 13, 2011

Re: [Pharo-project] Instantiating from a Symbol

by Norbert Hartl

Am 13.11.2011 um 10:17 schrieb Sven Van Caekenberghe: > Stef, > > On 12 Nov 2011, at 23:04, StÃ©phane Ducasse wrote: > >> environment should be used in a method while Smalltalk globals more for scripts. > > Yeah, but Nick's point is that #environment is a class method, not an instance method, and maybe it would be handy on the instance side. Absolutely. I want to have environments for code _and_ data. Not sure if it is applyable in a clean way into the same concept. But I like to be able to load a new version of my code into the same image. And I like to be able to run tests of my code without having side effects to my existing production data. Norbert

Nov. 13, 2011

Re: [Pharo-project] Instantiating from a Symbol

by Sven Van Caekenberghe

Stef, On 12 Nov 2011, at 23:04, StÃ©phane Ducasse wrote: > environment should be used in a method while Smalltalk globals more for scripts. Yeah, but Nick's point is that #environment is a class method, not an instance method, and maybe it would be handy on the instance side. Sven

Nov. 13, 2011