July 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] ConfigurationOfGoferProjectLoader ...

by Dale Henrichs

Geert Claes wrote: > Has anyone been able to load the ConfigurationOfGoferProjectLoader? I've been using 1.0-alpha2.1 a lot, but it does look like there is a problem with the released version ... I'll fix it. Dale

July 14, 2010

Re: [Pharo-project] [squeak-dev] [ANN] SimpleLogger released

by GermÃ¡n Arduino

Well, unfortunately I don't know deep the framework of Keith (as I said before is very heavy to my needs). Toothpick seems very well documented (http://www.metaprog.com/Toothpick/docs/index.html) even when I never used it because also is more than my needs. The other thing is don't know if run on Pharo. About my own small piece of code, yes, I can write some doc, and even extend it a bit (but not much, because I don't wants to add tons of functions). Exist somewhere somes guidelines about writing for the book? GermÃ¡n. 2010/7/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > about all the loger frameworks > > Stef > > On Jul 14, 2010, at 4:33 PM, GermÃ¡n Arduino wrote: > >> About the logger?? >> >> It's so simple...........but still if you think that may help..... >> >> Cheers. >> >> >> 2010/7/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> can you add a page on the book? >>> >>> Stef >>> >>> On Jul 14, 2010, at 1:04 PM, Mariano Martinez Peck wrote: >>> >>>> Hi German, Thanks very much for the ANN. >>>> >>>> Just in case, were you aware of SimpleLog, Toothpick and Logging ? >>>> >>>> http://wiki.squeak.org/squeak/3706 >>>> http://wiki.squeak.org/squeak/5890 >>>> >>>> Which are the differences/advantages of yours ? probably that at yours work in latests squeak and pharo versions >>>> >>>> thanks >>>> >>>> mariano >>>> >>>> >>>> >>>> On Wed, Jul 14, 2010 at 12:59 AM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: >>>> Hi: >>>> >>>> Frequently I need to log operations on text files for things I develop >>>> for my customers. >>>> >>>> I released now a tool (VERY simple) that I use to do so. >>>> >>>> I hope may be useful to someone. >>>> >>>> The url is http://www.squeaksource.com/SimpleLogger.html >>>> >>>> Cheers. >>>> GermÃ¡n. >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> ================================================= >> GermÃ¡n S. Arduino Â <gsa @ arsol.net> Â Twitter: garduino >> Arduino Software & Web Hosting Â http://www.arduinosoftware.com >> PasswordsPro Â http://www.passwordspro.com >> ================================================= >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 14, 2010

Re: [Pharo-project] [squeak-dev] [ANN] SimpleLogger released

by StÃ©phane Ducasse

about all the loger frameworks Stef On Jul 14, 2010, at 4:33 PM, GermÃ¡n Arduino wrote: > About the logger?? > > It's so simple...........but still if you think that may help..... > > Cheers. > > > 2010/7/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> can you add a page on the book? >> >> Stef >> >> On Jul 14, 2010, at 1:04 PM, Mariano Martinez Peck wrote: >> >>> Hi German, Thanks very much for the ANN. >>> >>> Just in case, were you aware of SimpleLog, Toothpick and Logging ? >>> >>> http://wiki.squeak.org/squeak/3706 >>> http://wiki.squeak.org/squeak/5890 >>> >>> Which are the differences/advantages of yours ? probably that at yours work in latests squeak and pharo versions >>> >>> thanks >>> >>> mariano >>> >>> >>> >>> On Wed, Jul 14, 2010 at 12:59 AM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: >>> Hi: >>> >>> Frequently I need to log operations on text files for things I develop >>> for my customers. >>> >>> I released now a tool (VERY simple) that I use to do so. >>> >>> I hope may be useful to someone. >>> >>> The url is http://www.squeaksource.com/SimpleLogger.html >>> >>> Cheers. >>> GermÃ¡n. >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > ================================================= > GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 14, 2010

[Pharo-project] running windows vm with input script

by Tudor Girba

Hi, I cannot figure out how to open a pharo image and run some script(s) specified from the Windows command line. On Mac/Linux, I would do: pharo pharo.image script.st Can anyone tell me how to achieve that on Windows? Cheers, Doru -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

July 14, 2010

Re: [Pharo-project] [squeak-dev] [ANN] SimpleLogger released

by GermÃ¡n Arduino

About the logger?? It's so simple...........but still if you think that may help..... Cheers. 2010/7/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > can you add a page on the book? > > Stef > > On Jul 14, 2010, at 1:04 PM, Mariano Martinez Peck wrote: > >> Hi German, Thanks very much for the ANN. >> >> Just in case, were you aware of SimpleLog, Toothpick and Logging ? >> >> http://wiki.squeak.org/squeak/3706 >> http://wiki.squeak.org/squeak/5890 >> >> Which are the differences/advantages of yours ? probably that at yours work in latests squeak and pharo versions >> >> thanks >> >> mariano >> >> >> >> On Wed, Jul 14, 2010 at 12:59 AM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: >> Hi: >> >> Frequently I need to log operations on text files for things I develop >> for my customers. >> >> I released now a tool (VERY simple) that I use to do so. >> >> I hope may be useful to someone. >> >> The url is http://www.squeaksource.com/SimpleLogger.html >> >> Cheers. >> GermÃ¡n. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

July 14, 2010

Re: [Pharo-project] [squeak-dev] [ANN] SimpleLogger released

by StÃ©phane Ducasse

can you add a page on the book? Stef On Jul 14, 2010, at 1:04 PM, Mariano Martinez Peck wrote: > Hi German, Thanks very much for the ANN. > > Just in case, were you aware of SimpleLog, Toothpick and Logging ? > > http://wiki.squeak.org/squeak/3706 > http://wiki.squeak.org/squeak/5890 > > Which are the differences/advantages of yours ? probably that at yours work in latests squeak and pharo versions > > thanks > > mariano > > > > On Wed, Jul 14, 2010 at 12:59 AM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: > Hi: > > Frequently I need to log operations on text files for things I develop > for my customers. > > I released now a tool (VERY simple) that I use to do so. > > I hope may be useful to someone. > > The url is http://www.squeaksource.com/SimpleLogger.html > > Cheers. > GermÃ¡n. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 14, 2010

[Pharo-project] ConfigurationOfGoferProjectLoader ...

by Geert Claes

Has anyone been able to load the ConfigurationOfGoferProjectLoader? -- View this message in context: http://forum.world.st/ConfigurationOfGoferProjectLoader-tp2288788p2288788.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 14, 2010

Re: [Pharo-project] [squeak-dev] [ANN] SimpleLogger released

by GermÃ¡n Arduino

Hi Mariano: Yes, I know both but honestly wanted something very simple.....May be I'm too lazy but can't afford to read a mail of this extension: http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-December/132923… :) Toothpick look better (to my needs) but still wanted something more simple. GermÃ¡n. 2010/7/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi German, Thanks very much for the ANN. > > Just in case, were you aware of SimpleLog, Toothpick and Logging ? > > http://wiki.squeak.org/squeak/3706 > http://wiki.squeak.org/squeak/5890 > > Which are the differences/advantages of yours ? probably that at yours work > in latests squeak and pharo versions > > thanks > > mariano > > > > On Wed, Jul 14, 2010 at 12:59 AM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: >> >> Hi: >> >> Frequently I need to log operations on text files for things I develop >> for my customers. >> >> I released now a tool (VERY simple) that I use to do so. >> >> I hope may be useful to someone. >> >> The url is http://www.squeaksource.com/SimpleLogger.html >> >> Cheers. >> GermÃ¡n. >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

July 14, 2010

Re: [Pharo-project] [squeak-dev] [ANN] SimpleLogger released

by Mariano Martinez Peck

Hi German, Thanks very much for the ANN. Just in case, were you aware of SimpleLog, Toothpick and Logging ? http://wiki.squeak.org/squeak/3706 http://wiki.squeak.org/squeak/5890 Which are the differences/advantages of yours ? probably that at yours work in latests squeak and pharo versions thanks mariano On Wed, Jul 14, 2010 at 12:59 AM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: > Hi: > > Frequently I need to log operations on text files for things I develop > for my customers. > > I released now a tool (VERY simple) that I use to do so. > > I hope may be useful to someone. > > The url is http://www.squeaksource.com/SimpleLogger.html > > Cheers. > GermÃ¡n. > >

July 14, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Hilaire Fernandes

Thanks Levente for your tips, they will be useful! Hilaire

July 14, 2010

[Pharo-project] [ANN] SimpleLogger released

by GermÃ¡n Arduino

Hi: Frequently I need to log operations on text files for things I develop for my customers. I released now a tool (VERY simple) that I use to do so. I hope may be useful to someone. The url is http://www.squeaksource.com/SimpleLogger.html Cheers. GermÃ¡n.

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

yes what I imply is that we do not want to have the runtime semantics changed because of a type system. Stef On Jul 13, 2010, at 5:05 PM, Johan Fabry wrote: > > Sorry, I did not invent the terminology, we'll just have to do with this ... > > On 12 Jul 2010, at 16:45, StÃ©phane Ducasse wrote: > >> instead of gradual typing I prefer the term pluggable types because it is really clear what it means. >> >> On Jul 12, 2010, at 10:03 PM, Johan Fabry wrote: >> >>> >>> Gradual typing could help there, doing optimisations where possible. Eric has a PhD student (Oscar) working on gradual typing, with Pharo as the test bed. Next semester there should start a second one with me (Esteban) that is going to look at the vm side of things: if type info is available, use it to optimise ... >>> >>> So, we are working on it ;-) >> > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 13, 2010

Re: [Pharo-project] Cleaning morphic?

by StÃ©phane Ducasse

Hi I got a flu last week. :) Now how to proceed: step by step :) Start little do it often. So what I suggest is that you go one fix at a time, you send it to the list, open a ticket, people get a chance to argue and we loop million of times. For example - I would like to understand if they are not things to be changed now that we have true bloclosure - for menu opening... like PluggableXXXX and fix that - I would like to have less subclass of StringHolder :) - Something good would be to check the fix Juan did in CUIS for the scrollbars and friends. Yes cleaning morphic is important. > I know morphic is one of the greatest issues Squeak and Pharo have. And I'm tired of the kilometric morph hierarchies with tons of methods that noone uses, and the impossible traceability of the morphic code... > > And I'm sure that a lot of people tried it before... And this isn't the highest priority. But I think morphic cleansing should be done. > > So, while i'm now in bed beacause of a flu, hehe, I want at least remove unused morph classes and unused methods... Or maybe we can separate some things from the core. Of course I will be "spamming" in the list asking for the changes I will do :P. > > what do you think? Do I open a ticket? > > Guille > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 13, 2010

Re: [Pharo-project] Ryerson University, Toronto

by StÃ©phane Ducasse

On Jul 13, 2010, at 5:21 PM, Chris Cunnington wrote: > Last night was a meeting of the Toronto Smalltalk Users Group. It was made clear to me that our host for the meetings (who wasn't there, because we meet on a patio in summer) at Ryerson University, Dr. Joshua Panar had chosen Pharo to introduce to his second year programming students. > > http://www.scs.ryerson.ca/~jpanar/ > > I pushed for Squeak and run over by Bob and Yanni. This is foul perfidy on their part of which they have not heard the last. > > It seems to me that a lot could be accomplished if somebody from the Pharo executive could send Josh some sort of email of introduction. He is in a position to do a lot for Pharo, and a single email from somebody on your side would doubtlessly energize him a great deal. I think he'd find that very encouraging. He's a very nice guy. ***Excellent***! I will contact him I converted all my lectures to powerpoint so that people can freely use them. http://stephane.ducasse.free.fr/Tmp/PowerPoint/ > > Chris > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 13, 2010

[Pharo-project] [ANN] new config versions for Seaside30, Grease, Magritte2, Pier2, Pier2AddOns

by Dale Henrichs

ConfigurationOfGrease - 1.0-alpha9.3 ConfigurationOfSeaside30 - 3.0.0-alpha5.15 ConfigurationOfMagritte2 - 2.0.5 ConfigurationOfPier2 - 2.0.6 ConfigurationOfPierAddOns2 - 2.0.6 ConfigurationOfSeaside - 1.0.5 The configurations are available in http://www.squeaksource.com/MetacelloRepository. Note that the mcz files in the Seaside3.0 config predates the mcz files in 3.0 RC that was recently announced, so I apologize for the potential confusion. We are shipping GemStone/S 64 2.4.4.1 very soon now and I needed to coordinate the releases of Seaside3.0/Magritte2/Pier2 that are available on GemStone. The announcement of 3.0 RC came too late to incorporate into our release cycle. I'll be pushing out updated configs shortly. The big change with this release is that there is a new 'Base' group defined that loads the minimal packages for running Seaside (i.e., no development packages, no examples, no java script. etc.) thus making it possible to perform a load into a production image of only the packages/features you want. The new versions of the Magritte2, Pier2 and PierAddOns2 are structured to load only what is absolutely needed for each of those projects, again making it possible to load Pier2 into an image without having the entire Seaside3.0 development come along. One of the upshots of loading only the minimum required is that you will need to choose an adaptor to explicitly load (Kom or Swazoo for Pharo/Squeak folks). So if you want to load a minimal Pier2 and use the Kom adaptor, you will evaluate an expression like the following (after loading the Seaside3.0 and Pier2 configurations: (ConfigurationOfPier2 project version: '2.0.6') load. (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') load: #( 'Seaside-Adaptors-Comanche' ). If you want to add the Seaside3.0 development environment to your image, you would evaluate the following: (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') load: #( 'Development' ). and if you wanted the development environment plus tests you'd evaluate the following: (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') load: #( 'Development Tests' ). As for the ConfigurationOfSeaside, I have decided that the 'Seaside 3.0' target will load the full Seaside3.0 code base. However, I have added a 'Seaside 3.0 Production' target that loads the minimal Seaside packages plus both adaptors. I have updated the #workspace method with additional examples. For the GemStone users out there keep your eyes peeled for the announcement of GemStone/S 64 2.4.4.1 where I will provide additional (mostly) GemStone-specific information. Well with as many moving pieces involved in this announcement I expect that there will be a stitch or two dropped (which reminds me that you ought to make sure you are using the latest version of Metacello when loaded Seaside3.0) so feel free to drop me a line with comments/problems and I will see if I can address them. Now that GemStone has caught up with Pharo and Squeak (very soon, I promise:) I don't anticipate making these multi-config coordinated releases any time soon... Putting together a Seaside 3.0 RC config is next up on the list... Dale

July 13, 2010

[Pharo-project] Ryerson University, Toronto

by Chris Cunnington

Last night was a meeting of the Toronto Smalltalk Users Group. It was made clear to me that our host for the meetings (who wasn't there, because we meet on a patio in summer) at Ryerson University, Dr. Joshua Panar had chosen Pharo to introduce to his second year programming students. http://www.scs.ryerson.ca/~jpanar/ I pushed for Squeak and run over by Bob and Yanni. This is foul perfidy on their part of which they have not heard the last. It seems to me that a lot could be accomplished if somebody from the Pharo executive could send Josh some sort of email of introduction. He is in a position to do a lot for Pharo, and a single email from somebody on your side would doubtlessly energize him a great deal. I think he'd find that very encouraging. He's a very nice guy. Chris

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Johan Fabry

Sorry, I did not invent the terminology, we'll just have to do with this ... On 12 Jul 2010, at 16:45, StÃ©phane Ducasse wrote: > instead of gradual typing I prefer the term pluggable types because it is really clear what it means. > > On Jul 12, 2010, at 10:03 PM, Johan Fabry wrote: > >> >> Gradual typing could help there, doing optimisations where possible. Eric has a PhD student (Oscar) working on gradual typing, with Pharo as the test bed. Next semester there should start a second one with me (Esteban) that is going to look at the vm side of things: if type info is available, use it to optimise ... >> >> So, we are working on it ;-) > -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Johan Fabry

As far as I can see, he is in the formalizing (a subset of) Smalltalk phase. We must be patient, such formal stuff cannot be hurried ;-) On 12 Jul 2010, at 16:45, StÃ©phane Ducasse wrote: > I would love to hear more about oscar. I would love to know where the libraries could be improved to have more coherent type information. > I told him when I visited you but so far we got no feedback. We will see if there are some results. > > Stef > >> >> Gradual typing could help there, doing optimisations where possible. Eric has a PhD student (Oscar) working on gradual typing, with Pharo as the test bed. Next semester there should start a second one with me (Esteban) that is going to look at the vm side of things: if type info is available, use it to optimise ... >> >> So, we are working on it ;-) > -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

July 13, 2010

Re: [Pharo-project] Cleaning morphic?

by Levente Uzonyi

On Tue, 13 Jul 2010, Guillermo Polito wrote: > I know morphic is one of the greatest issues Squeak and Pharo have. And I'm > tired of the kilometric morph hierarchies with tons of methods that noone > uses, and the impossible traceability of the morphic code... You can't be sure that a method or class is not used if you only look at the senders or users. Morphic uses a lot of automatic generated selectors combined with #perform:withArguments: (and friends) which makes it very hard to track down senders. Though checking the senders of #asSymbol can help. Levente > > And I'm sure that a lot of people tried it before... And this isn't the > highest priority. But I think morphic cleansing should be done. > > So, while i'm now in bed beacause of a flu, hehe, I want at least remove > unused morph classes and unused methods... Or maybe we can separate some > things from the core. Of course I will be "spamming" in the list asking for > the changes I will do :P. > > what do you think? Do I open a ticket? > > Guille >

July 13, 2010

[Pharo-project] Cleaning morphic?

by Guillermo Polito

I know morphic is one of the greatest issues Squeak and Pharo have. And I'm tired of the kilometric morph hierarchies with tons of methods that noone uses, and the impossible traceability of the morphic code... And I'm sure that a lot of people tried it before... And this isn't the highest priority. But I think morphic cleansing should be done. So, while i'm now in bed beacause of a flu, hehe, I want at least remove unused morph classes and unused methods... Or maybe we can separate some things from the core. Of course I will be "spamming" in the list asking for the changes I will do :P. what do you think? Do I open a ticket? Guille

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

ok we are in sync. Stef On Jul 13, 2010, at 4:21 PM, Marcus Denker wrote: > > On Jul 13, 2010, at 3:56 PM, StÃ©phane Ducasse wrote: > >> Strange this is not what gilad mentioned. >> A pluggable type system: you can plug multiples one and the runtime is not influenced by type systems. >> > > Yes. > > Gradual Typing is *not* about multiple type systems. It's just *one* Type System. Which has the > nice property of dealing nicely with code in the case of having no type annotations. > > One can implement Gradual Typing without any Pluggable Types. Then it's the only type-system the > language has. Type-check would in this case not be optional. It would be always done, but without > annotations leading to no static checking done. But it could actually influence the language semantics > (e.g. one could imagine a language that compiles in dynamic checks following the gradual type > checker in the case of no annotation. Instead of a runtime that has the checks build in like smalltalk). > > In turn, one could provide a Type-System based on Gradual Typing *on top* of a Pluggable Types > infrastrustructure.This then would be a type-system that is optional, not influencing language semantics. > > So both are orthogonal. But of course related. (how to type-check dynamic systems without making them static). > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Marcus Denker

On Jul 13, 2010, at 3:56 PM, StÃ©phane Ducasse wrote: > Strange this is not what gilad mentioned. > A pluggable type system: you can plug multiples one and the runtime is not influenced by type systems. > Yes. Gradual Typing is *not* about multiple type systems. It's just *one* Type System. Which has the nice property of dealing nicely with code in the case of having no type annotations. One can implement Gradual Typing without any Pluggable Types. Then it's the only type-system the language has. Type-check would in this case not be optional. It would be always done, but without annotations leading to no static checking done. But it could actually influence the language semantics (e.g. one could imagine a language that compiles in dynamic checks following the gradual type checker in the case of no annotation. Instead of a runtime that has the checks build in like smalltalk). In turn, one could provide a Type-System based on Gradual Typing *on top* of a Pluggable Types infrastrustructure.This then would be a type-system that is optional, not influencing language semantics. So both are orthogonal. But of course related. (how to type-check dynamic systems without making them static). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

Hilaire if you remove monticello you can get a lot of space (lukas checked and in 1.2 (we have 3.5 mb just for duration) On Jul 13, 2010, at 9:58 AM, Hilaire Fernandes wrote: > Le 13/07/2010 09:42, Mariano Martinez Peck a Ã©crit : >> Hilarie: first question, do you want to make faster what? The >> development there or the deploy of a particular application? > > > I want first to improve the user experience under this 12 years old CPU power technology (XO-1): make UI more responsive is the first and only issue. > > I am compiling tips and suggestion on DrGeo Todo list: > http://community.ofset.org/index.php/DrGeo_Todo > > > Next of course the deployment is another aspect related to configuration, see my other post. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

Strange this is not what gilad mentioned. A pluggable type system: you can plug multiples one and the runtime is not influenced by type systems. Stef >> instead of gradual typing I prefer the term pluggable types because it is really clear what it means. >> > Pluggable types is differnt to "gradual typing". > > Pluggable types: Infrastucture to plug any type system (with infrastructure to allow to infer > or or ignore non-annotated code). > > Gradual Types: One (kind of) Type System where type annotations are optional: > > http://ecee.colorado.edu/~siek/gradualtyping.html > > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Levente Uzonyi

On Mon, 12 Jul 2010, Hilaire Fernandes wrote: > Le 12/07/2010 18:08, Levente Uzonyi a Ã©crit : > >>> Which tweaking can be applied to the image for a better user experience? >> >> You can use MVC, it works well on much slower computers... oh wait... >> >> Sorry, I couldn't resist. :) > > Your joke remind me a funny event occurring one year ago. I was chatting with > an old friend working in the bank sector in Geneva. He asked me what's up > today, I told him my interest in Smalltalk, he joked I was interested in > computer archeology. It looked funny to me as well. :) > > >> Try getting rid of gradients, dropshadows, etc. Use a plain old strikefont > > Yes, the sugar theme is flat black and white. > > >> without anti-aliasing. If you can build a custom vm, make sure that you >> optimize it for the platform and build all modules external, except for > > > Yes, beside -Ox option are there any additional one you know about to be > effective? Yes, if your target is the XO-1, you can optimize your vm for the Geode LX. With gcc 4.3+ I'd try this first: -march=geode -mmmx -m3dnow -O3 -fomit-frame-pointer then some other architectures (march), like i486, i586, i686 or k6-2. If you are using an older compiler, you can still use i486, i585, i686 and k6-2. Since only the user experience matters, you can rely on the browser benchmark and pick the config with the best results. If two results are close, you can check tinybenchmarks and base your decision on that. Of course you can run macrobenchmarks if you have the time. According to this: http://forum.world.st/iPhone-Cog-Stack-VM-performance-numbers-td2286605.htm… you should definitely build a stack vm. Building a small vm (all modules external which are not loaded at startup) is better, because the vm itself uses less memory. This also means that the chance for a cache miss is lower (tinyBenchmarks shows a 10% improvement with this on my pc). (I didn't look at the code, but the Cog vm could also be used if you can replace the sse2 instructions with 3dnow.) Levente > >> those which are loaded when the image starts. You can also try using the >> new StackVM. > > Will do later. > > Thanks for your tips. > > Hilaire > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Hilaire Fernandes

Hi Julian, Thanks for your tips. Several people (Stef, Mariano, Marcus) already told me how good you did with Cuis to produce a small, coherent and effective Smalltalk, all these activities around Smalltalk are both exciting and a source of motivation to show out there how nice Smalltalk can be for developers and users. Right now, my hands are full with DrGeo refactoring, VM compilation to produce a VM for XO-1 (done now) and now configuring an image itself to be a nice host for the full, new bleeding DrGeo UI, polymorph based[1]. Serge also wants to have a lean Pharo on XO to port and to develop educational applications. We agree to share the workload: I am finishing the Sugar Polymorph theme (an important part to get a faster UI, on top of a coherent UI with the rest of the XO Sugar environment) and Serge will looks at the image configuration and optimization. Your help will be very welcome. Hilaire [1] http://blog.ofset.org/hilaire/index.php?post/2010/06/07/DrGeoII-new-user-in… Le 13/07/2010 12:28, Juan Vuletich a Ã©crit : > I suggest testing Cuis. In Cuis do 'Preferences veryBigFonts' and you > get a quite usable system on the XO. Then, use the profiler, to see > where Pharo spends time and Cuis doesn't. That's are the parts you need > to understand and optimize. And you can take code from Cuis to make it > faster (it is all MIT). BTW, anti aliased fonts are ok if StrikeFonts > (i.e. the Cuis DejaVu fonts), and most likely, using 16bpp Display > instead of 32 doesn't make much difference. > > Cheers, > Juan Vuletich

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Juan Vuletich

Hilaire Fernandes wrote: > Le 13/07/2010 09:42, Mariano Martinez Peck a Ã©crit : >> Hilarie: first question, do you want to make faster what? The >> development there or the deploy of a particular application? > > > I want first to improve the user experience under this 12 years old > CPU power technology (XO-1): make UI more responsive is the first and > only issue. > > I am compiling tips and suggestion on DrGeo Todo list: > http://community.ofset.org/index.php/DrGeo_Todo > > > Next of course the deployment is another aspect related to > configuration, see my other post. > Hi Hilaire, I suggest testing Cuis. In Cuis do 'Preferences veryBigFonts' and you get a quite usable system on the XO. Then, use the profiler, to see where Pharo spends time and Cuis doesn't. That's are the parts you need to understand and optimize. And you can take code from Cuis to make it faster (it is all MIT). BTW, anti aliased fonts are ok if StrikeFonts (i.e. the Cuis DejaVu fonts), and most likely, using 16bpp Display instead of 32 doesn't make much difference. Cheers, Juan Vuletich

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Mariano Martinez Peck

On Tue, Jul 13, 2010 at 9:58 AM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > Le 13/07/2010 09:42, Mariano Martinez Peck a Ã©crit : > > Hilarie: first question, do you want to make faster what? The >> development there or the deploy of a particular application? >> > > > I want first to improve the user experience under this 12 years old CPU > power technology (XO-1): make UI more responsive is the first and only > issue. > > I am compiling tips and suggestion on DrGeo Todo list: > http://community.ofset.org/index.php/DrGeo_Todo > > > Next of course the deployment is another aspect related to configuration, > see my other post. > > Ok ok ok. What I would to is to: - Start from PharoCore, of course. Not dev. Take a core and load what you need. To script such loads, you can use Gofer. If you want to use Metacello, you can take your conf and load it. It will bootstrap metacello, and then, once you have installed it, with ConfigurationOfMetacello >> unload you con can remove Metacello from the system. - Do some cleaning to the image. Check the stuff done in ScriptLoader >> cleanUpForProduction. There are a lot of interesting things there - Use standard fonts and as they said, without antialaising - For the VM you can also compile a minimal VM. I did that with MacOS where I compiled only the 4 or 5 plugins that were needed. I am not sure if you win something, thus. - Check and try this email: http://forum.world.st/Are-random-refactorings-welcome-td2283957.html#a22839… - Of course, try Cog. - I would use the SystemBrowser that comes with the Core. Not OB neither O2. - Enable fastDragWindowForMorphic - Don't use annotation panes. CHeck also issues 2403 - Use Pharo 1.1 that is much faster than 1.0 That's all that came to my mind. Not sure what could help. Good luck and let us know. Cheers Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Hilaire Fernandes

Le 13/07/2010 09:42, Mariano Martinez Peck a Ã©crit : > Hilarie: first question, do you want to make faster what? The > development there or the deploy of a particular application? I want first to improve the user experience under this 12 years old CPU power technology (XO-1): make UI more responsive is the first and only issue. I am compiling tips and suggestion on DrGeo Todo list: http://community.ofset.org/index.php/DrGeo_Todo Next of course the deployment is another aspect related to configuration, see my other post.

July 13, 2010

Re: [Pharo-project] Alien on Pharo 1.2 on Mac

by Luc Fabresse

Hi All, I pushed a new version of Alien in the the Alien repo ( http://www.squeaksource.com/Alien) (thanks to John who granted us access). This version (#64) makes the 40 Alien tests green in Pharo 1.2-12049 . Since the ConfigurationOfAlien has not been changed yet, you can load it using: Gofer new url: 'http://www.squeaksource.com/Alien' ; package: 'ConfigurationOfAlien'; load. (ConfigurationOfAlien project version: '1.0-baseline') load: #('Core' 'Tests' 'LibC') Luc On Tue, Jul 6, 2010 at 9:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > you do not have access to the alien repository? > can you ask john to gve you access to it? > > On Jul 6, 2010, at 3:41 PM, Luc Fabresse wrote: > > > Hi all, > > > > We provide a usable version of Alien to Pharo 1.2 (all tests green on > OSX). > > We committed the corrected package on the Ocean squeaksource repository : > http://squeaksource.com/Ocean > > (Alien-Core-LucFabresse.64.mcz) > > > > We didn't look in details to the method > SystemDictionary>>recreateSpecialObjectsArray introduced by Alien-Core-63. > > It is now unsed because Smalltalk points to a SmalltalkImage. > > This need to be checked before possibly removal. > > > > Another point would be to update the metacello configuration > ConfigurationOfAlien. > > > > Luc and Noury > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 13, 2010

[Pharo-project] please sign the license agreement

by StÃ©phane Ducasse

Hi all even if the simple fact that you submit code to the bug tracker or to the inbox means that you release your code under MIT for pharo, please take the license agreement, fill it up and send it to us. We got burn in the past with such problem http://code.google.com/p/pharo/wiki/LicenseAgreement Stef

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Mariano Martinez Peck

Hilarie: first question, do you want to make faster what? The development there or the deploy of a particular application? On Tue, Jul 13, 2010 at 9:15 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jul 12, 2010, at 10:45 PM, StÃ©phane Ducasse wrote: > > > instead of gradual typing I prefer the term pluggable types because it is > really clear what it means. > > > Pluggable types is differnt to "gradual typing". > > Pluggable types: Infrastucture to plug any type system (with infrastructure > to allow to infer > or or ignore non-annotated code). > > Gradual Types: One (kind of) Type System where type annotations are > optional: > > http://ecee.colorado.edu/~siek/gradualtyping.html<http://ecee.colorado.edu/%7Esiek/gradualtyping.html> > > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Marcus Denker

On Jul 12, 2010, at 10:45 PM, StÃ©phane Ducasse wrote: > instead of gradual typing I prefer the term pluggable types because it is really clear what it means. > Pluggable types is differnt to "gradual typing". Pluggable types: Infrastucture to plug any type system (with infrastructure to allow to infer or or ignore non-annotated code). Gradual Types: One (kind of) Type System where type annotations are optional: http://ecee.colorado.edu/~siek/gradualtyping.html Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 13, 2010

[Pharo-project] Configuration how-to

by Hilaire Fernandes

Request for tips, suggestions and direction. What is the state of the art to: - load package - change preference setting (as the one seen in the Pharo setting tools. - remove unnecessary bits Hilaire

July 13, 2010

Re: [Pharo-project] [Vm-dev] Tracing on Linux

by Schwab,Wilhelm K

I think I found it. Trying to do this without callbacks in hand lead me to use a lot of C where I previously used block closures (that is not all bad, but it should not be necessary). As a result, I jam the data into a void pointer that is part of the library-designed function signature; with callbacks and closures, I simply shared the data inside the Smalltalk image and ignored the offending pointers. In this design, I put the points in a matrix that they treat as void* and therefore immediately indirected the pointer in the functions - big mistake, as they initially call the functions (for reasons I can't quite figure out) before the solver is configured and the data is known to the library. The pointer is therefore null and indirecting it was zapping me. A grander design might later reveal itself, but for now, it looks like a really sloppy part of the library. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Monday, July 12, 2010 4:34 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux Dave, I must respectfully disagree: the point is to see what Pharo "thinks" is happening in certain situations, so I need to see tracing info from it and from the library. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, July 12, 2010 3:54 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux Using #stdOut from the image would not be useful for debugging a primitive or an FFI callout. Either use a real debugger (gdb et al) or put the fprintf someplace where you can see the parameters exactly as passed to the function. Dave On Mon, Jul 12, 2010 at 10:35:36AM -0400, Schwab,Wilhelm K wrote: > Dave, > > Any thoughts on mixing fprint()/fflush() in the .so with #stdOut in the image? I found #helloWorld, but some tinkering suggests that it is very sensitive to using #lf vs. #cr and/or does not like #flush. Does any of that sound familiar? > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > David T. Lewis > Sent: Monday, July 12, 2010 5:32 AM > To: Squeak Virtual Machine Development Discussion > Cc: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux > > On Sun, Jul 11, 2010 at 05:30:35PM -0400, Schwab,Wilhelm K wrote: > > > > I am trying to track down a segmentation fault in calling into the Gnu Scientific Library. These are things that I had working under Windows+Dolphin and am now trying to do with Pharo and Linux. Offsets to structure elements and sizes of structures are possible snags, but the calls that are failing should be reasonably independent of such things: I call the relevant allocation method and pass along the pointer, so even if my interpretation of the structs is bogus, I would still expect the functions to succeed. That is all the more true of new functions that I am adding for testing purposes. > > > > The GSL functionality is split into two libraries, and the .so modules appear to be hobbled on Linux due to circular dependencies between them. A wrapper .so that is linked to both libraries seems to allow me to call "all" of the functions (the few I have tried to access) and gives a home for code of my own. > > > > I went so far as to compile some GSL sample code, and it does not crash. I further linked it to my wrapper library and it still works calling the GSL functions through the wrapper (or at least I *think* that's happening). I plan to gradually sneak up on the crash by moving things into my library and then hopefully into Pharo via FFI. > > > > On Windows, I would use OutputDebugString() to write tracing messages to look at what is happening until I found the problem. How do you unix VM gurus tackle such debugging problems? > > > > Bill, > > To write strings to output, use fprintf() followed by fflush(). > Don't forget the fflush or you'll never figure anything out ;) > > To use a debugger, compile with CFLAGS=-g (enable debugging info, no compiler optimization), then run the VM under gdb or one of the gui front ends to gdb such as ddd. Put a breakpoint in your function, and you're good to go. > > Assuming you are using up to date sources from Subversion, run "platforms/unix/configure --help" for more build options. > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 13, 2010

Re: [Pharo-project] Sequential Dictionary

by Joel Turnbull

Thank you, it's working beautifully HernÃ¡n :) 2010/7/12 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > Hi Joel, > > You may try the attached OrderedDictionary, I've been using it for some > time. > Cheers, > > HernÃ¡n > > 2010/7/12 Joel Turnbull <joelbywan(a)gmail.com>: > > > > Spent some time but was not quite able to get OrderedDictionary working. > > However I see the idea is for the Dictionary to hold an OrderedCollection > > that is synchronized with the Dictionary's array. > > > > I think that's enough for me to go on to implement my own for the limited > > dictionary protocol I need to support. > > > > I looked in the Seaside packages for subclasses of Dictionary, or classes > > named like Dictionary, but I didn't find anything. > > > > I got a little lost looking at BTree, I should probably take the time to > > look at that someday. > > > > Thanks guys. > > > > > > > > On Sun, Jul 11, 2010 at 11:45 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> > >> On Sun, 11 Jul 2010, Joel Turnbull wrote: > >> > >>> What is the group's recommendation for creating a sequential > Dictionary? > >>> i.e. A Dictionary who's associations are ordered. > >>> > >>> Is there any precedent for this? Or does it sound like I'm barking up > the > >>> wrong tree? > >>> > >>> In my model, I've subclassed Dictionary into QuantityDictionary to > store > >>> line items, where the key is the item and the value is the quantity of > >>> the > >>> item. It validates that the value is always a numeric, removes the > >>> association when the value goes below zero, and other stuff specific to > >>> my > >>> application. > >>> > >>> Now I'm finding it makes sense to be able to order these associations. > >>> Imagine a recipe ingredient list, where you add and edit quantities of > >>> ingredients, and you want to put the ingredients that you use earliest > in > >>> the recipe at the top of the ingredient list. > >>> > >>> Before I put any more work into it, I just wanted to make sure that a > >>> sequential dictionary makes sense, and get your ideas on how to > generally > >>> go > >>> about implementing that? > >> > >> A "sequential dictionary" can mean a lot of different things. There are > >> some implementations with different semantics available. See these for > >> example: > >> http://squeaksource.com/BTree.html > >> http://forum.world.st/OrderedDictionary-td277320.html > >> > >> If you just want to iterate over your dictionary once in the sorted > order, > >> then the best thing to do is to collect your data into an array, sort > the > >> array, then iterate over that sorted array. > >> > >> > >> Levente > >> > >>> > >>> Thanks. > >>> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 13, 2010

Re: [Pharo-project] [Vm-dev] Tracing on Linux

by Schwab,Wilhelm K

Dave, I must respectfully disagree: the point is to see what Pharo "thinks" is happening in certain situations, so I need to see tracing info from it and from the library. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, July 12, 2010 3:54 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux Using #stdOut from the image would not be useful for debugging a primitive or an FFI callout. Either use a real debugger (gdb et al) or put the fprintf someplace where you can see the parameters exactly as passed to the function. Dave On Mon, Jul 12, 2010 at 10:35:36AM -0400, Schwab,Wilhelm K wrote: > Dave, > > Any thoughts on mixing fprint()/fflush() in the .so with #stdOut in the image? I found #helloWorld, but some tinkering suggests that it is very sensitive to using #lf vs. #cr and/or does not like #flush. Does any of that sound familiar? > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > David T. Lewis > Sent: Monday, July 12, 2010 5:32 AM > To: Squeak Virtual Machine Development Discussion > Cc: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux > > On Sun, Jul 11, 2010 at 05:30:35PM -0400, Schwab,Wilhelm K wrote: > > > > I am trying to track down a segmentation fault in calling into the Gnu Scientific Library. These are things that I had working under Windows+Dolphin and am now trying to do with Pharo and Linux. Offsets to structure elements and sizes of structures are possible snags, but the calls that are failing should be reasonably independent of such things: I call the relevant allocation method and pass along the pointer, so even if my interpretation of the structs is bogus, I would still expect the functions to succeed. That is all the more true of new functions that I am adding for testing purposes. > > > > The GSL functionality is split into two libraries, and the .so modules appear to be hobbled on Linux due to circular dependencies between them. A wrapper .so that is linked to both libraries seems to allow me to call "all" of the functions (the few I have tried to access) and gives a home for code of my own. > > > > I went so far as to compile some GSL sample code, and it does not crash. I further linked it to my wrapper library and it still works calling the GSL functions through the wrapper (or at least I *think* that's happening). I plan to gradually sneak up on the crash by moving things into my library and then hopefully into Pharo via FFI. > > > > On Windows, I would use OutputDebugString() to write tracing messages to look at what is happening until I found the problem. How do you unix VM gurus tackle such debugging problems? > > > > Bill, > > To write strings to output, use fprintf() followed by fflush(). > Don't forget the fflush or you'll never figure anything out ;) > > To use a debugger, compile with CFLAGS=-g (enable debugging info, no compiler optimization), then run the VM under gdb or one of the gui front ends to gdb such as ddd. Put a breakpoint in your function, and you're good to go. > > Assuming you are using up to date sources from Subversion, run "platforms/unix/configure --help" for more build options. > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

On Jul 12, 2010, at 11:16 PM, Nicolas Cellier wrote: > 2010/7/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > I would love to hear more about oscar. I would love to know where the libraries could be improved to have more coherent type information. > I told him when I visited you but so far we got no feedback. We will see if there are some results. > > Stef > > > Oh, you mean following the steps of Strongtalk... Yes getting advantage of strong typing without the inconvenient. You could have checkers that help us and still have a pure dynamically typed language. Some years ago a student did an experiment at bern on that. Stef

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Nicolas Cellier

2010/7/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > I would love to hear more about oscar. I would love to know where the > libraries could be improved to have more coherent type information. > I told him when I visited you but so far we got no feedback. We will see if > there are some results. > > Stef > > Oh, you mean following the steps of Strongtalk... Nicolas > > > > Gradual typing could help there, doing optimisations where possible. Eric > has a PhD student (Oscar) working on gradual typing, with Pharo as the test > bed. Next semester there should start a second one with me (Esteban) that is > going to look at the vm side of things: if type info is available, use it to > optimise ... > > > > So, we are working on it ;-) > > > > On 12 Jul 2010, at 15:53, StÃ©phane Ducasse wrote: > > > >> - high optimized (I would be curious to know if we could "seal" > some packages and in this case use a lot of inlining > > > > -- > > Johan Fabry > > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry<http://dcc.uchile.cl/%7Ejfabry> > > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 12, 2010

Re: [Pharo-project] [Vm-dev] Tracing on Linux

by David T. Lewis

Using #stdOut from the image would not be useful for debugging a primitive or an FFI callout. Either use a real debugger (gdb et al) or put the fprintf someplace where you can see the parameters exactly as passed to the function. Dave On Mon, Jul 12, 2010 at 10:35:36AM -0400, Schwab,Wilhelm K wrote: > Dave, > > Any thoughts on mixing fprint()/fflush() in the .so with #stdOut in the image? I found #helloWorld, but some tinkering suggests that it is very sensitive to using #lf vs. #cr and/or does not like #flush. Does any of that sound familiar? > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis > Sent: Monday, July 12, 2010 5:32 AM > To: Squeak Virtual Machine Development Discussion > Cc: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux > > On Sun, Jul 11, 2010 at 05:30:35PM -0400, Schwab,Wilhelm K wrote: > > > > I am trying to track down a segmentation fault in calling into the Gnu Scientific Library. These are things that I had working under Windows+Dolphin and am now trying to do with Pharo and Linux. Offsets to structure elements and sizes of structures are possible snags, but the calls that are failing should be reasonably independent of such things: I call the relevant allocation method and pass along the pointer, so even if my interpretation of the structs is bogus, I would still expect the functions to succeed. That is all the more true of new functions that I am adding for testing purposes. > > > > The GSL functionality is split into two libraries, and the .so modules appear to be hobbled on Linux due to circular dependencies between them. A wrapper .so that is linked to both libraries seems to allow me to call "all" of the functions (the few I have tried to access) and gives a home for code of my own. > > > > I went so far as to compile some GSL sample code, and it does not crash. I further linked it to my wrapper library and it still works calling the GSL functions through the wrapper (or at least I *think* that's happening). I plan to gradually sneak up on the crash by moving things into my library and then hopefully into Pharo via FFI. > > > > On Windows, I would use OutputDebugString() to write tracing messages to look at what is happening until I found the problem. How do you unix VM gurus tackle such debugging problems? > > > > Bill, > > To write strings to output, use fprintf() followed by fflush(). > Don't forget the fflush or you'll never figure anything out ;) > > To use a debugger, compile with CFLAGS=-g (enable debugging info, no compiler optimization), then run the VM under gdb or one of the gui front ends to gdb such as ddd. Put a breakpoint in your function, and you're good to go. > > Assuming you are using up to date sources from Subversion, run "platforms/unix/configure --help" for more build options. > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

instead of gradual typing I prefer the term pluggable types because it is really clear what it means. On Jul 12, 2010, at 10:03 PM, Johan Fabry wrote: > > Gradual typing could help there, doing optimisations where possible. Eric has a PhD student (Oscar) working on gradual typing, with Pharo as the test bed. Next semester there should start a second one with me (Esteban) that is going to look at the vm side of things: if type info is available, use it to optimise ... > > So, we are working on it ;-) > > On 12 Jul 2010, at 15:53, StÃ©phane Ducasse wrote: > >> - high optimized (I would be curious to know if we could "seal" some packages and in this case use a lot of inlining > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

I would love to hear more about oscar. I would love to know where the libraries could be improved to have more coherent type information. I told him when I visited you but so far we got no feedback. We will see if there are some results. Stef > > Gradual typing could help there, doing optimisations where possible. Eric has a PhD student (Oscar) working on gradual typing, with Pharo as the test bed. Next semester there should start a second one with me (Esteban) that is going to look at the vm side of things: if type info is available, use it to optimise ... > > So, we are working on it ;-) > > On 12 Jul 2010, at 15:53, StÃ©phane Ducasse wrote: > >> - high optimized (I would be curious to know if we could "seal" some packages and in this case use a lot of inlining > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Johan Fabry

Gradual typing could help there, doing optimisations where possible. Eric has a PhD student (Oscar) working on gradual typing, with Pharo as the test bed. Next semester there should start a second one with me (Esteban) that is going to look at the vm side of things: if type info is available, use it to optimise ... So, we are working on it ;-) On 12 Jul 2010, at 15:53, StÃ©phane Ducasse wrote: > - high optimized (I would be curious to know if we could "seal" some packages and in this case use a lot of inlining -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

> Your joke remind me a funny event occurring one year ago. I was chatting with an old friend working in the bank sector in Geneva. He asked me what's up today, I told him my interest in Smalltalk, he joked I was interested in computer archeology. It looked funny to me as well. > > Your friend is right: we still use IT of the 70s... > But maybe he's still using those of the late 60s himself (you know,{}, no boolean, source files, include files, preprocessor directives, compiler flags,...) > That's something I usually answer. > > Nicolas :) Even if it would be good to invent the next generation - secure - extremely modular/malleable (bootstrap and coevolution of the vm would be really cool) - high optimized (I would be curious to know if we could "seal" some packages and in this case use a lot of inlining - customizable memory management - better mop Stef

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Nicolas Cellier

2010/7/12 Hilaire Fernandes <hilaire.fernandes(a)gmail.com> > Le 12/07/2010 18:08, Levente Uzonyi a Ã©crit : > > Which tweaking can be applied to the image for a better user experience? >>> >> >> You can use MVC, it works well on much slower computers... oh wait... >> >> Sorry, I couldn't resist. :) >> > > Your joke remind me a funny event occurring one year ago. I was chatting > with an old friend working in the bank sector in Geneva. He asked me what's > up today, I told him my interest in Smalltalk, he joked I was interested in > computer archeology. It looked funny to me as well. > Your friend is right: we still use IT of the 70s... But maybe he's still using those of the late 60s himself (you know,{}, no boolean, source files, include files, preprocessor directives, compiler flags,...) That's something I usually answer. Nicolas > > Try getting rid of gradients, dropshadows, etc. Use a plain old strikefont >> > > Yes, the sugar theme is flat black and white. > > > without anti-aliasing. If you can build a custom vm, make sure that you >> optimize it for the platform and build all modules external, except for >> > > > Yes, beside -Ox option are there any additional one you know about to be > effective? > > those which are loaded when the image starts. You can also try using the >> new StackVM. >> > > Will do later. > > Thanks for your tips. > > Hilaire > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

> You can use MVC, it works well on much slower computers... oh wait... :) Levente it was a good one. :) > Sorry, I couldn't resist. :) :) I know the feeling. Now we removed MVC from pharo not because we did not value it but because we want a clean infrastructure (where several UI system could be loaded) and this was not with a isMorphic code everywhere that we could move. So sometimes you have to take decision so that you can get again agile so that you can reconsider your own decision. > Try getting rid of gradients, dropshadows, etc. Use a plain old strikefont > without anti-aliasing. If you can build a custom vm, make sure that you optimize it for the platform and build all modules external, except for those which are loaded when the image starts. You can also try using the new StackVM. > And you can also run the following version of the browser test to see where can you improve the performance: > > | savedMorphs | > savedMorphs := World submorphs. > World removeAllMorphs."heh, heh" > [ > [ > 10 timesRepeat: [ Browser fullOnClass: Object selector: #yourself ]. > World submorphs do: [ :m | m delete. self currentWorld doOneCycle] ] > ensure: [ World addAllMorphs: savedMorphs ] ] timeProfile. > > > Levente > >> >> Thanks to share any thought, even random ones. >> >> >> Hilaire >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 12, 2010

Re: [Pharo-project] iPhone Cog Stack VM, performance numbers

by StÃ©phane Ducasse

This is an excellent news and the benchmark is a realistic action! Thanks you all! On Jul 12, 2010, at 9:01 PM, John McIntosh wrote: > As always it's difficult to determine how best to benchmark. So given: > > | savedMorphs | > savedMorphs := World submorphs. > World removeAllMorphs. > self halt. > ^ [[10 > timesRepeat: [Browser fullOnClass: Object selector: #yourself]. > World submorphs > do: [:m | > m delete. > self currentWorld doOneCycle]] > ensure: [World addAllMorphs: savedMorphs]] timeToRun inspect > > > I can say that the Cog Stack VM on the iPhone produces numbers like > > 48.081 seconds > 47.858 seconds > > The original VM did: > > 74.415 seconds > 74.257 seconds > > making the iPhone COG VM 1.55x faster > > > A 2.33ghz mac book pro mac vm 5.7b1 does it in about 8.3 seconds > with a COG JIT VM 5.8 that takes 2.6 seconds or about 3.2 faster > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Hilaire Fernandes

Le 12/07/2010 18:08, Levente Uzonyi a Ã©crit : >> Which tweaking can be applied to the image for a better user experience? > > You can use MVC, it works well on much slower computers... oh wait... > > Sorry, I couldn't resist. :) Your joke remind me a funny event occurring one year ago. I was chatting with an old friend working in the bank sector in Geneva. He asked me what's up today, I told him my interest in Smalltalk, he joked I was interested in computer archeology. It looked funny to me as well. > Try getting rid of gradients, dropshadows, etc. Use a plain old strikefont Yes, the sugar theme is flat black and white. > without anti-aliasing. If you can build a custom vm, make sure that you > optimize it for the platform and build all modules external, except for Yes, beside -Ox option are there any additional one you know about to be effective? > those which are loaded when the image starts. You can also try using the > new StackVM. Will do later. Thanks for your tips. Hilaire

July 12, 2010

[Pharo-project] iPhone Cog Stack VM, performance numbers

by John McIntosh

As always it's difficult to determine how best to benchmark. So given: | savedMorphs | savedMorphs := World submorphs. World removeAllMorphs. self halt. ^ [[10 timesRepeat: [Browser fullOnClass: Object selector: #yourself]. World submorphs do: [:m | m delete. self currentWorld doOneCycle]] ensure: [World addAllMorphs: savedMorphs]] timeToRun inspect I can say that the Cog Stack VM on the iPhone produces numbers like 48.081 seconds 47.858 seconds The original VM did: 74.415 seconds 74.257 seconds making the iPhone COG VM 1.55x faster A 2.33ghz mac book pro mac vm 5.7b1 does it in about 8.3 seconds with a COG JIT VM 5.8 that takes 2.6 seconds or about 3.2 faster -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd.Â http://www.smalltalkconsulting.com ===========================================================================

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Hilaire Fernandes

Le 12/07/2010 18:04, StÃ©phane Ducasse a Ã©crit : > thanks for trying. > did you try cuis to see a difference? No > I know that juan optimize scrollbars and others.

July 12, 2010