- Pharo-dev - lists.pharo.org

[Pharo-project] Class rename on materialization

by Martin Dias

Hi. We have recently discussed in a couple of threads about serialization & class renames. I want to ask you for the following case, because I'm not sure what should be the expected result. Suppose we serialize: Array with: OldClass new with: OldClass with: #OldClass. Then, we specify to the materializer that OldClass has been renamed to NewClass. Now, should we expect that result first -------> a NewClass second --> NewClass third ------> #NewClass or... result third ------> #OldClass ? In other words, should a class rename affect to every symbol in the graph? Thanks, MartÃn

Dec. 15, 2011

[Pharo-project] Magma in production ?

by Francois Stephany

Is there anybody using the Magma OODB in production? For what kind of application? How does it behave under load? How large is your dataset? How do you perform external backup? What's the best setup? One dedicated image? Cheers, Francois -- http://tulipemoutarde.be BE: +32 (0)65 709 131 CA: +1 778 558 3225

Dec. 15, 2011

Re: [Pharo-project] NB Bug?

by Schwab,Wilhelm K

I see this as a missing feature for one reason: as silly as the syntax might be, it is used in the wild. Until gcc rejects it, it would be nice if NB would accept it. The closer we get toward what should be our ultimate goal (header files in, working binding out), the more details like these matter. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Fernando Olivero [fernando.olivero(a)usi.ch] Sent: Wednesday, December 14, 2011 8:08 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] NB Bug? Your right, this isnt a bug, NativeBoost is very well tested and works really nice! I should reformulate the comment: 'if i new user of Native Boost, and i copy and paste some Library method, to create a NB method in smalltalk, and if it happens that that particular method is written foo(void), then will i be able to know the origin of the DNU ?, that i should just put foo() ?" For me it took a while of debugging before i understood the issue, maybe others less eager to debug will think its a bug? Surely with a good documentation and examples, it shouldn't be a problem. Fernando On Thu, Dec 15, 2011 at 1:23 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 15 December 2011 00:12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> I've insist. >> >> Because maybe somebody else runs into this bug, and thinks that NB is >> broken, instead of understanding they should use new C syntax. For >> examples i was using the latest Pango code. > > but this is NOT a bug. maybe a missing feature but not a bug. > Is it so hard to put empty braces instead of void? :) And besides > empty braces it is valid C syntax. > >> >> If you want we could raise a warning, suggesting changing the code? >> (maybe too disturbing). >> > no, i just dont understand why complicating a code for nothing? > You can define a callout to functions with no arguments. > If you would not be able to do so, then this can be considered a bug. > >> Fernando >> >> On Wed, Dec 14, 2011 at 2:10 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 14 December 2011 01:17, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>>> Igor, is this a bug? >>>> >>>> When parsing methods that send native functions withouth arguments , >>>> void, theres a DNU. >>>> For example in the following method: >>>> >>>> ^ self pangoCairoNbCall:#(PangoCairoFontMap >>>> pango_cairo_font_map_get_default ( void ) ) >>>> >>>> >>>> I fixed it like this: >>>> >>>> usesMethodArguments >>>> "first check wether my single argument is void" >>>> ^(fnSpec arguments size = 1 ==> [fnSpec arguments first class ~= >>>> NBVoid]) and:[ fnSpec arguments anySatisfy: [:type | type loader >>>> usesSTStack ] ] >>>> >>>> >>> >>> Well, the function signature syntax are not strictly following C. >>> Just use empty parens for functions with no arguments. This is quite >>> archaic C syntax, which is really not important to support. >>> >>> Or i can add this patch if you insist. :) >>> >>> -- >>> Best regards, >>> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko.

Dec. 15, 2011

Re: [Pharo-project] 1.3, PBE and lab setups

by Serge Stinckwich

2011/12/15 Dave Mason <dmason(a)mason-rose.ca>: > I am trying to get our local admins to set up labs so students can use the > latest Pharo. > > Currently we have 1.2 and PBE .image files and by removing the field in the > INI file that specified the image, if you clicked on Pharo, you'd get a > dialogue asking which image you wanted. Â All of these are on read-only > mounts, so if you want to save to the image, you need to copy the image to > your home directory and then you could navigate to that image file on > startup. Â Dropping an image on the executable works fine, though. > > Additionally, the PBE book doesn't play well with 1.3 (things that the book > says die when you try them). Â Apparently you can't open the PBE image from > the 1.3 binary without it crashing, either. > > So I have 3 questions: > > 1) is 1.3 the system to use, or will 1.4 be stable soon? > > 2) is the PBE book getting updated to work with a vanilla 1.3/1.4 image? There is no plan at the moment to do that, but you could help adapt the Pharo Book to the new images. All the contents of the book is here: https://github.com/SquareBracketAssociates/PharoByExample-english Maybe we can have branches for each version of Pharo ? pharo1.2, pharo1.3, etc ... Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Dec. 15, 2011

Re: [Pharo-project] NB Bug?

by Fernando Olivero

Your right, this isnt a bug, NativeBoost is very well tested and works really nice! I should reformulate the comment: 'if i new user of Native Boost, and i copy and paste some Library method, to create a NB method in smalltalk, and if it happens that that particular method is written foo(void), then will i be able to know the origin of the DNU ?, that i should just put foo() ?" For me it took a while of debugging before i understood the issue, maybe others less eager to debug will think its a bug? Surely with a good documentation and examples, it shouldn't be a problem. Fernando On Thu, Dec 15, 2011 at 1:23 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 15 December 2011 00:12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> I've insist. >> >> Because maybe somebody else runs into this bug, and thinks that NB is >> broken, instead of understanding they should use new C syntax. For >> examples i was using the latest Pango code. > > but this is NOT a bug. maybe a missing feature but not a bug. > Is it so hard to put empty braces instead of void? :) And besides > empty braces it is valid C syntax. > >> >> If you want we could raise a warning, suggesting changing the code? >> (maybe too disturbing). >> > no, i just dont understand why complicating a code for nothing? > You can define a callout to functions with no arguments. > If you would not be able to do so, then this can be considered a bug. > >> Fernando >> >> On Wed, Dec 14, 2011 at 2:10 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 14 December 2011 01:17, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>>> Igor, is this a bug? >>>> >>>> When parsing methods that send native functions withouth arguments , >>>> void, theres a DNU. >>>> For example in the following method: >>>> >>>> ^ self pangoCairoNbCall:#(PangoCairoFontMap >>>> pango_cairo_font_map_get_default ( void ) ) >>>> >>>> >>>> I fixed it like this: >>>> >>>> usesMethodArguments >>>> "first check wether my single argument is void" >>>> ^(fnSpec arguments size = 1 ==> [fnSpec arguments first class ~= >>>> NBVoid]) and:[ fnSpec arguments anySatisfy: [:type | type loader >>>> usesSTStack ] ] >>>> >>>> >>> >>> Well, the function signature syntax are not strictly following C. >>> Just use empty parens for functions with no arguments. This is quite >>> archaic C syntax, which is really not important to support. >>> >>> Or i can add this patch if you insist. :) >>> >>> -- >>> Best regards, >>> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko.

Dec. 15, 2011

Re: [Pharo-project] NB Bug?

by Igor Stasenko

On 15 December 2011 00:12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > I've insist. > > Because maybe somebody else runs into this bug, and thinks that NB is > broken, instead of understanding they should use new C syntax. For > examples i was using the latest Pango code. but this is NOT a bug. maybe a missing feature but not a bug. Is it so hard to put empty braces instead of void? :) And besides empty braces it is valid C syntax. > > If you want we could raise a warning, suggesting changing the code? > (maybe too disturbing). > no, i just dont understand why complicating a code for nothing? You can define a callout to functions with no arguments. If you would not be able to do so, then this can be considered a bug. > Fernando > > On Wed, Dec 14, 2011 at 2:10 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 14 December 2011 01:17, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>> Igor, is this a bug? >>> >>> When parsing methods that send native functions withouth arguments , >>> void, theres a DNU. >>> For example in the following method: >>> >>> ^ self pangoCairoNbCall:#(PangoCairoFontMap >>> pango_cairo_font_map_get_default ( void ) ) >>> >>> >>> I fixed it like this: >>> >>> usesMethodArguments >>> "first check wether my single argument is void" >>> ^(fnSpec arguments size = 1 ==> [fnSpec arguments first class ~= >>> NBVoid]) and:[ fnSpec arguments anySatisfy: [:type | type loader >>> usesSTStack ] ] >>> >>> >> >> Well, the function signature syntax are not strictly following C. >> Just use empty parens for functions with no arguments. This is quite >> archaic C syntax, which is really not important to support. >> >> Or i can add this patch if you insist. :) >> >> -- >> Best regards, >> Igor Stasenko. > -- Best regards, Igor Stasenko.

Dec. 15, 2011

Re: [Pharo-project] NB Bug?

by Fernando Olivero

I've insist. Because maybe somebody else runs into this bug, and thinks that NB is broken, instead of understanding they should use new C syntax. For examples i was using the latest Pango code. If you want we could raise a warning, suggesting changing the code? (maybe too disturbing). Fernando On Wed, Dec 14, 2011 at 2:10 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 December 2011 01:17, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> Igor, is this a bug? >> >> When parsing methods that send native functions withouth arguments , >> void, theres a DNU. >> For example in the following method: >> >> ^ self pangoCairoNbCall:#(PangoCairoFontMap >> pango_cairo_font_map_get_default ( void ) ) >> >> >> I fixed it like this: >> >> usesMethodArguments >> "first check wether my single argument is void" >> ^(fnSpec arguments size = 1 ==> [fnSpec arguments first class ~= >> NBVoid]) and:[ fnSpec arguments anySatisfy: [:type | type loader >> usesSTStack ] ] >> >> > > Well, the function signature syntax are not strictly following C. > Just use empty parens for functions with no arguments. This is quite > archaic C syntax, which is really not important to support. > > Or i can add this patch if you insist. :) > > -- > Best regards, > Igor Stasenko.

Dec. 14, 2011

Re: [Pharo-project] Better Gofer error messages

by Janko MivÅ¡ek

Done. S, StÃ©phane Ducasse piÅ¡e: > open a bug entry and we will fix that :) > You could even provide the code and it will be faster >> >>>> Please please, let someone improve Gofer error messages, which are now >>>> totally non-understandable. Check in advance if some package is there >>>> and say "No package with that name", or even better, "no package with >>>> expected name: Blabla6.xxx" or something. >> >>> can you point which messages are a problem >> >> Say you evaluate this script: >> >> Gofer new >> squeaksource: 'Fuel'; >> package: 'ConfigurationOFuel'; >> load. >> (Smalltalk at: #ConfigurationOfFuel) load. >> >> Did you notice a typo in script? Hardly. Now see what exception look like: >> >> Error: Unable to resolve ConfigurationOFuel >> >> GoferPackageReference(Object)>>error: >> GoferPackageReference(GoferReference)>>resolveWith: >> [:each | each resolveWith: self] in Gofer>>resolved >> Array(SequenceableCollection)>>collect: >> Gofer>>resolved >> ... >> >> My thinking: What is it unable to resolve, what is to be resolved >> anyway? But if error will be something like: >> >> "Unable to find or resolve package ConfigurationOFuel, check >> the name. See Gofer class comment for more" >> >> It will certainly lead me to check for the typo first and only if >> failed, go to class comment and find a wiki page. >> >>>> What it is now is unusable, sorry. To prepare a right script is a big >>>> pain. Specially because there are nowhere rules how packages are >>>> resolved by a name. It will help if in exception at least a link to the >>>> some wiki with rules would be shown. >> >>> why don't you use metacello? >>> there 45 pages documentation on it >> >> Gofer is needed for Metacello too and yes, Metacello has similar >> problems with not very helpful error messages. >> >> See how Fuel guys improve error reporting in recent Fuel, after having >> the same cryptic messages before. >> >> Best regards >> Janko >> >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >>

Dec. 14, 2011

Re: [Pharo-project] [ VM ]Smalltalk getSystemAttribute:

by Eliot Miranda

On Wed, Dec 14, 2011 at 1:13 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi Eliot. So, do we need to change something from image side? > Hopefully not. But you might try testing launching from the command line and accessing image arguments and vm arguments. Hopefully "Smalltalk image arguments" and "Smalltalk vm arguments" answer the right things (and different things). To help in your testing I'm attaching the script I use to launch from the command line on Mac OS. I should include this in the Cog VM distribution but it isn't part of the .app bundle. I put it in ~/bin and edit it to point at the .app bundle I want. Note that this script can be linked with different names to launch different VMs (i.e. I cal it all of ocsfvm oscavm oscdvm oscfmtvm et al to launch the production, assert, debug and multi-threaded etc VMs). HTH Eliot > > On Thu, Dec 1, 2011 at 12:20 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> My initial implementation was in error. I've now changed it back to >> 0 => executable name >> -1 .. -n => VM arguments *including* image (if explicitly supplied). >> >> Apologies. >> >> >> On Wed, Nov 30, 2011 at 12:03 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> >>> we will have to check if this impacts some of our parameter handling. >>> >>> Stef >>> >>> Begin forwarded message: >>> >>> VM.r2518/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2518/>. >>> >>> CogVM binaries as per VMMaker.oscog-eem.139/r2518. >>> >>> Add access to VM arguments to Mac. Make Windows, Mac and Unix >>> consistent: >>> Smalltalk getSystemAttribute: >>> -1 => executable name >>> -2 .. -n => VM arguments *including* image (if >>> explicitly supplied). >>> Replace win32 command line parsing with unixesque code using >>> CommandLineToArgvW. >>> >>> linux launch script: >>> Cope with old linuxes use of /lib/tls hack for an optional >>> thread-local-storage >>> version of libc/libpthread. The launch scripts add >>> /lib/tls:/usr/lib/tls: to >>> LD_LIBRARY_PATH instead of /lib:/usr/lib: if the VM is linked to >>> /lib/tls/libc. >>> -- >>> best, >>> Eliot >>> >>> >>> >>> >>> >>> >> >> >> -- >> best, >> Eliot >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Dec. 14, 2011

Re: [Pharo-project] [ VM ]Smalltalk getSystemAttribute:

by Mariano Martinez Peck

Hi Eliot. So, do we need to change something from image side? On Thu, Dec 1, 2011 at 12:20 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > My initial implementation was in error. I've now changed it back to > 0 => executable name > -1 .. -n => VM arguments *including* image (if explicitly supplied). > > Apologies. > > > On Wed, Nov 30, 2011 at 12:03 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> we will have to check if this impacts some of our parameter handling. >> >> Stef >> >> Begin forwarded message: >> >> VM.r2518/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2518/>. >> >> CogVM binaries as per VMMaker.oscog-eem.139/r2518. >> >> Add access to VM arguments to Mac. Make Windows, Mac and Unix consistent: >> Smalltalk getSystemAttribute: >> -1 => executable name >> -2 .. -n => VM arguments *including* image (if explicitly >> supplied). >> Replace win32 command line parsing with unixesque code using >> CommandLineToArgvW. >> >> linux launch script: >> Cope with old linuxes use of /lib/tls hack for an optional >> thread-local-storage >> version of libc/libpthread. The launch scripts add /lib/tls:/usr/lib/tls: >> to >> LD_LIBRARY_PATH instead of /lib:/usr/lib: if the VM is linked to >> /lib/tls/libc. >> -- >> best, >> Eliot >> >> >> >> >> >> > > > -- > best, > Eliot > > -- Mariano http://marianopeck.wordpress.com

Dec. 14, 2011