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

Re: [Pharo-project] SqueakSSL fails...

by Levente Uzonyi

On Fri, 30 Jul 2010, Andrei Stebakov wrote: > It fails at the following statement: > (decoded readInto: buffer startingAt: index count: count) = count > ifFalse:[self error: 'Unexpected read failure']. > > In SecureSocketStream>>initialize it decoded defined as > decoded := ReadStream on: (ByteArray new: 20000) from: 1 to: 0. > > Maybe decoded is supposed to become a SocketStream later in the game, > but at this point it's still a ReadStream which doesn't understand > #readInto:startingAt:count: Hm no. It just wasn't integrated: http://code.google.com/p/pharo/issues/detail?id=2177 . Levente > > Can anyone reproduce this in Pharo 1.1? Just evaluate "WebClient > httpGet: 'https://www.google.com/search?q=squeak'." > > 2010/7/30 Levente Uzonyi <leves(a)elte.hu>: >> On Fri, 30 Jul 2010, Andrei Stebakov wrote: >> >>> Apparently #readInto:startingAt:count: is not supported by ReadStream >>> Pharo 1.1... >> >> SecureSocketStream is a subclass of SocketStream which has a method named >> #readInto:startingAt:count:. >> >> >> Levente >> >>> >>> >>> On Fri, Jul 30, 2010 at 5:46 PM, Andrei Stebakov <lispercat(a)gmail.com> >>> wrote: >>>> >>>> Well, I put it there when Pharo was running. Now that I restarted >>>> Pharo I got a different error: >>>> When I execute "WebClient httpGet: >>>> 'https://www.google.com/search?q=squeak'." I got: >>>> >>>> ReadStream(Object)>>doesNotUnderstand: #readInto:startingAt:count: >>>> SecureSocketStream>>receiveDataInto:startingAt: >>>> SecureSocketStream>>receiveAvailableData >>>> SecureSocketStream(SocketStream)>>upToAll: >>>> WebResponse>>readFrom: >>>> WebClient>>sendRequest:content:size: >>>> WebClient>>sendRequest: >>>> WebClient>>httpGet:do: >>>> WebClient>>httpGet: >>>> WebClient class>>httpGet: >>>> UndefinedObject>>DoIt >>>> Compiler>>evaluate:in:to:notifying:ifFail:logged: >>>> [] in TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection >>>> BlockClosure>>on:do: >>>> TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection >>>> TextMorphForShoutEditor(ParagraphEditor)>>doIt >>>> [] in TextMorphForShoutEditor(ParagraphEditor)>>doIt: >>>> TextMorphForShoutEditor(ParagraphEditor)>>terminateAndInitializeAround: >>>> TextMorphForShoutEditor(ParagraphEditor)>>doIt: >>>> TextMorphForShoutEditor(ParagraphEditor)>>dispatchOnKeyEvent:with: >>>> >>>> >>>> >>>> >>>> On Fri, Jul 30, 2010 at 4:47 PM, Andrei Stebakov <lispercat(a)gmail.com> >>>> wrote: >>>>> >>>>> I've downloaded the SqueakSSL.dll plugin and put it in the root folder. >>>>> Also I've downloaded >>>>> SqueakSSL-Core >>>>> SqueakSSL-Plugin >>>>> SqueakSSL-Tests >>>>> >>>>> All tests passed. >>>>> Now when I try to execute "SqueakSSL google: 'Squeak'." >>>>> It fails creating the module in >>>>> >>>>> primitiveSSLCreate >>>>> Â Â Â Â "Primitive. Creates and returns a new SSL handle" >>>>> >>>>> Â Â Â Â <primitive: 'primitiveCreate' module: 'SqueakSSL'> >>>>> Â Â Â Â ^self primitiveFailed >>>>> >>>>> How can I fix it? >>>>> >>>>> Thank you, >>>>> Andrei >>>>> >>>> >>> >>> _______________________________________________ >>> 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 31, 2010

Re: [Pharo-project] Underscores in 1.1??

by StÃ©phane Ducasse

Don't overuse that :) We do not like print_on_ ( ...) ;D Stef On Jul 25, 2010, at 3:05 PM, Schwab,Wilhelm K wrote: > THANKS!!!!! to all involved in getting this done. > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] > Sent: Sunday, July 25, 2010 4:32 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Underscores in 1.1?? > >> Is 1.1 able to handle underscores in method *and* class names? Is this really behind us now? > > Yes, all identifiers support underscore characters everywhere. Also > temporary and instance variables. And also in the refactoring engine. > > The only problem I just noticed in the editor is that double clicking > on a variable with a underscore does not change the selection > correctly. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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 31, 2010

Re: [Pharo-project] running Magma tests in 1.1

by Mariano Martinez Peck

On Sat, Jul 31, 2010 at 4:57 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > Yes, the implementation of fileExists: was changed, so it no longer > iterates over entire directory contents, but tries to open the file. Sadly, > the Unix vm contains a bug which means relative links will not be resolved > correctly. > A fix from Cog has been submitted, but no release has been made which > obtains it yet. > > Hi Henry, Thanks a lot. Do you know if we have a test in PharoCore that test this? At least a failing/error one due to this? It would be great to have it. The other vms are ok ? thanks mariano > Cheers, > Henry > > Den 30. juli 2010 kl. 23:09 skrev Chris Muller <asqueaker(a)gmail.com>: > > > To run the test-suite for Magma 1.1r2 in Pharo: > > > > - Proceed past two warnings about "FlapTab" when loading Magma. > > - Revert FileDirectory>>#fileExists: to the prior version. > > - Remove #testClassSchemaUpgrades. > > - Load OSProcess. > > > > The second and third steps, above, I believe may be regressions in Pharo > 1.1. > > > > In Pharo 1.1: > > > > FileDirectory default fileExists: '/bin/sh' "---> false" > > > > but the file does, indeed, exist as a soft-link. Squeak answers true > > and, I'll bet, so does Pharo 1.0, so I'm not sure if there is a > > problem here or not. > > > > #testClassSchemaUpgrades tests Magma's ability to keep up with > > class-schema changes in the image. Usually class-schemas change only > > in development, not production systems so maybe it's not a big deal. > > But still, it can be very convenient develop new class schemas while > > connected to a persistent Magma store. Magma makes use of the > > SystemChangeNotifier to do this. I don't know if Pharo cleaned > > something with SystemChangeNotifier or a regression happened, but I > > don't have time to debug it right now. Certainly, if there is a > > problem with Magma I will fix it, but I'm not convinced of that yet. > > > > - Chris > > > > _______________________________________________ > > 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 31, 2010

[Pharo-project] Limitation of number os literals in a method?

by nullPointer

I get that error when I try save a CLView builded with the UIBuilder More than 256 literals referenced. You must split or otherwise simplify this method. The 257th literal is: 128 Select Proceed to continue, or close this window to cancel the operation. How I can solve that problem? The method than I try save is generated programmatically... Thanks -- View this message in context: http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp230874… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 31, 2010

[Pharo-project] [ANN] DrGeo release 10.08

by Hilaire Fernandes

Dear all, I am please to announce the DrGeo release 10.08. This is an universal application working identically for GNU/Linux, Windows and Mac OS X. http://blog.ofset.org/hilaire/index.php?post/2010/07/30/DrGeo-release-10.08… Hilaire

July 31, 2010

Re: [Pharo-project] running Magma tests in 1.1

by Henrik Johansen

Yes, the implementation of fileExists: was changed, so it no longer iterates over entire directory contents, but tries to open the file. Sadly, the Unix vm contains a bug which means relative links will not be resolved correctly. A fix from Cog has been submitted, but no release has been made which obtains it yet. Cheers, Henry Den 30. juli 2010 kl. 23:09 skrev Chris Muller <asqueaker(a)gmail.com>: > To run the test-suite for Magma 1.1r2 in Pharo: > > - Proceed past two warnings about "FlapTab" when loading Magma. > - Revert FileDirectory>>#fileExists: to the prior version. > - Remove #testClassSchemaUpgrades. > - Load OSProcess. > > The second and third steps, above, I believe may be regressions in Pharo 1.1. > > In Pharo 1.1: > > FileDirectory default fileExists: '/bin/sh' "---> false" > > but the file does, indeed, exist as a soft-link. Squeak answers true > and, I'll bet, so does Pharo 1.0, so I'm not sure if there is a > problem here or not. > > #testClassSchemaUpgrades tests Magma's ability to keep up with > class-schema changes in the image. Usually class-schemas change only > in development, not production systems so maybe it's not a big deal. > But still, it can be very convenient develop new class schemas while > connected to a persistent Magma store. Magma makes use of the > SystemChangeNotifier to do this. I don't know if Pharo cleaned > something with SystemChangeNotifier or a regression happened, but I > don't have time to debug it right now. Certainly, if there is a > problem with Magma I will fix it, but I'm not convinced of that yet. > > - Chris > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 31, 2010

Re: [Pharo-project] [squeak-dev] [ANN] Magma 1.1r2

by Miguel Enrique CobÃ¡ MartÃnez

> OK, I've copied them to "Magma" too. I will upload the SAR file to > SqueakMap too, soonish. Two more package missing in Magma repo: Ma exception handling-cmm.36.mcz Ma object serialization tester-cmm.32.mcz It is specified by the 1.1r2 mcm. In Magma repository there are: Ma exception handling-cmm.33.mcz Ma object serialization tester-cmm.30.mcz Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

July 31, 2010

Re: [Pharo-project] SqueakSSL fails...

by Andrei Stebakov

It fails at the following statement: (decoded readInto: buffer startingAt: index count: count) = count ifFalse:[self error: 'Unexpected read failure']. In SecureSocketStream>>initialize it decoded defined as decoded := ReadStream on: (ByteArray new: 20000) from: 1 to: 0. Maybe decoded is supposed to become a SocketStream later in the game, but at this point it's still a ReadStream which doesn't understand #readInto:startingAt:count: Can anyone reproduce this in Pharo 1.1? Just evaluate "WebClient httpGet: 'https://www.google.com/search?q=squeak'." 2010/7/30 Levente Uzonyi <leves(a)elte.hu>: > On Fri, 30 Jul 2010, Andrei Stebakov wrote: > >> Apparently #readInto:startingAt:count: is not supported by ReadStream >> Pharo 1.1... > > SecureSocketStream is a subclass of SocketStream which has a method named > #readInto:startingAt:count:. > > > Levente > >> >> >> On Fri, Jul 30, 2010 at 5:46 PM, Andrei Stebakov <lispercat(a)gmail.com> >> wrote: >>> >>> Well, I put it there when Pharo was running. Now that I restarted >>> Pharo I got a different error: >>> When I execute "WebClient httpGet: >>> 'https://www.google.com/search?q=squeak'." I got: >>> >>> ReadStream(Object)>>doesNotUnderstand: #readInto:startingAt:count: >>> SecureSocketStream>>receiveDataInto:startingAt: >>> SecureSocketStream>>receiveAvailableData >>> SecureSocketStream(SocketStream)>>upToAll: >>> WebResponse>>readFrom: >>> WebClient>>sendRequest:content:size: >>> WebClient>>sendRequest: >>> WebClient>>httpGet:do: >>> WebClient>>httpGet: >>> WebClient class>>httpGet: >>> UndefinedObject>>DoIt >>> Compiler>>evaluate:in:to:notifying:ifFail:logged: >>> [] in TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection >>> BlockClosure>>on:do: >>> TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection >>> TextMorphForShoutEditor(ParagraphEditor)>>doIt >>> [] in TextMorphForShoutEditor(ParagraphEditor)>>doIt: >>> TextMorphForShoutEditor(ParagraphEditor)>>terminateAndInitializeAround: >>> TextMorphForShoutEditor(ParagraphEditor)>>doIt: >>> TextMorphForShoutEditor(ParagraphEditor)>>dispatchOnKeyEvent:with: >>> >>> >>> >>> >>> On Fri, Jul 30, 2010 at 4:47 PM, Andrei Stebakov <lispercat(a)gmail.com> >>> wrote: >>>> >>>> I've downloaded the SqueakSSL.dll plugin and put it in the root folder. >>>> Also I've downloaded >>>> SqueakSSL-Core >>>> SqueakSSL-Plugin >>>> SqueakSSL-Tests >>>> >>>> All tests passed. >>>> Now when I try to execute "SqueakSSL google: 'Squeak'." >>>> It fails creating the module in >>>> >>>> primitiveSSLCreate >>>> Â Â Â Â "Primitive. Creates and returns a new SSL handle" >>>> >>>> Â Â Â Â <primitive: 'primitiveCreate' module: 'SqueakSSL'> >>>> Â Â Â Â ^self primitiveFailed >>>> >>>> How can I fix it? >>>> >>>> Thank you, >>>> Andrei >>>> >>> >> >> _______________________________________________ >> 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 31, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by csrabak＠bol.com.br

Em 30/07/2010 01:12, Serge Stinckwich < serge.stinckwich(a)gmail.com > escreveu: > I dunno of the translation of COBOL in french, but i remember when i > was in high school in the 80ies having using applications built in > LSE (Language Symbolique d'Enseignement). It was a kind of BASIC > written in french. More information here: > http://en.wikipedia.org/wiki/LSE_%28programming_language%29 > and in french here: > http://fr.wikipedia.org/wiki/LSE_%28langage_de_programmation%29 I > remember doing german lessons with LSE programs. One way to trick > the programs was to stop the application, to look at the name of > variable used to give the answer. After that everytime you replyed > with the name of variable, every exercice was done right ! ;-) Here in Brasil in the seventies we had a didactic programming language called HIPO (which is the suffix for Hypothetical in Portuguese) which was sort of the MIX language devised by D. Knuth. In the eighties a Pascal like language called LEAL (which means 'loyal' in Portuguese) was issued. But no tricks like the discovered by you have been reported for these educational languages... []s -- Cesar Rabak

July 31, 2010

Re: [Pharo-project] SqueakSSL fails...

by Levente Uzonyi

On Fri, 30 Jul 2010, Andrei Stebakov wrote: > Apparently #readInto:startingAt:count: is not supported by ReadStream > Pharo 1.1... SecureSocketStream is a subclass of SocketStream which has a method named #readInto:startingAt:count:. Levente > > > On Fri, Jul 30, 2010 at 5:46 PM, Andrei Stebakov <lispercat(a)gmail.com> wrote: >> Well, I put it there when Pharo was running. Now that I restarted >> Pharo I got a different error: >> When I execute "WebClient httpGet: >> 'https://www.google.com/search?q=squeak'." I got: >> >> ReadStream(Object)>>doesNotUnderstand: #readInto:startingAt:count: >> SecureSocketStream>>receiveDataInto:startingAt: >> SecureSocketStream>>receiveAvailableData >> SecureSocketStream(SocketStream)>>upToAll: >> WebResponse>>readFrom: >> WebClient>>sendRequest:content:size: >> WebClient>>sendRequest: >> WebClient>>httpGet:do: >> WebClient>>httpGet: >> WebClient class>>httpGet: >> UndefinedObject>>DoIt >> Compiler>>evaluate:in:to:notifying:ifFail:logged: >> [] in TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection >> BlockClosure>>on:do: >> TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection >> TextMorphForShoutEditor(ParagraphEditor)>>doIt >> [] in TextMorphForShoutEditor(ParagraphEditor)>>doIt: >> TextMorphForShoutEditor(ParagraphEditor)>>terminateAndInitializeAround: >> TextMorphForShoutEditor(ParagraphEditor)>>doIt: >> TextMorphForShoutEditor(ParagraphEditor)>>dispatchOnKeyEvent:with: >> >> >> >> >> On Fri, Jul 30, 2010 at 4:47 PM, Andrei Stebakov <lispercat(a)gmail.com> wrote: >>> I've downloaded the SqueakSSL.dll plugin and put it in the root folder. >>> Also I've downloaded >>> SqueakSSL-Core >>> SqueakSSL-Plugin >>> SqueakSSL-Tests >>> >>> All tests passed. >>> Now when I try to execute "SqueakSSL google: 'Squeak'." >>> It fails creating the module in >>> >>> primitiveSSLCreate >>> Â Â Â Â "Primitive. Creates and returns a new SSL handle" >>> >>> Â Â Â Â <primitive: 'primitiveCreate' module: 'SqueakSSL'> >>> Â Â Â Â ^self primitiveFailed >>> >>> How can I fix it? >>> >>> Thank you, >>> Andrei >>> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 30, 2010

Re: [Pharo-project] [squeak-dev] [ANN] Magma 1.1r2

by Ramiro Diaz Trepat

This is great new, Thanks Chris 2010/7/30 Chris Muller <asqueaker(a)gmail.com> > > Good, I will base the configuration packages version number on this sar. > > It will be named 1.1r2 or will be 1.1r3 (due to the deletion of a test > > in the package you mentioned before, maybe isn't big enough to deserve a > > new release and it was a "hurry" release maybe can we consider this a > > typo and consider the sar the official 1.1r2 release) > > Yes, it was just the removal of one test, so please stay with 1.1r2. > I'm pretty certain it's not going to affect any of the millions of > folks who have downloaded Magma since yesterday... :) > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma >

July 30, 2010

Re: [Pharo-project] SqueakSSL fails...

by Andrei Stebakov

Apparently #readInto:startingAt:count: is not supported by ReadStream Pharo 1.1... On Fri, Jul 30, 2010 at 5:46 PM, Andrei Stebakov <lispercat(a)gmail.com> wrote: > Well, I put it there when Pharo was running. Now that I restarted > Pharo I got a different error: > When I execute "WebClient httpGet: > 'https://www.google.com/search?q=squeak'." I got: > > ReadStream(Object)>>doesNotUnderstand: #readInto:startingAt:count: > SecureSocketStream>>receiveDataInto:startingAt: > SecureSocketStream>>receiveAvailableData > SecureSocketStream(SocketStream)>>upToAll: > WebResponse>>readFrom: > WebClient>>sendRequest:content:size: > WebClient>>sendRequest: > WebClient>>httpGet:do: > WebClient>>httpGet: > WebClient class>>httpGet: > UndefinedObject>>DoIt > Compiler>>evaluate:in:to:notifying:ifFail:logged: > [] in TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection > BlockClosure>>on:do: > TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection > TextMorphForShoutEditor(ParagraphEditor)>>doIt > [] in TextMorphForShoutEditor(ParagraphEditor)>>doIt: > TextMorphForShoutEditor(ParagraphEditor)>>terminateAndInitializeAround: > TextMorphForShoutEditor(ParagraphEditor)>>doIt: > TextMorphForShoutEditor(ParagraphEditor)>>dispatchOnKeyEvent:with: > > > > > On Fri, Jul 30, 2010 at 4:47 PM, Andrei Stebakov <lispercat(a)gmail.com> wrote: >> I've downloaded the SqueakSSL.dll plugin and put it in the root folder. >> Also I've downloaded >> SqueakSSL-Core >> SqueakSSL-Plugin >> SqueakSSL-Tests >> >> All tests passed. >> Now when I try to execute "SqueakSSL google: 'Squeak'." >> It fails creating the module in >> >> primitiveSSLCreate >> Â Â Â Â "Primitive. Creates and returns a new SSL handle" >> >> Â Â Â Â <primitive: 'primitiveCreate' module: 'SqueakSSL'> >> Â Â Â Â ^self primitiveFailed >> >> How can I fix it? >> >> Thank you, >> Andrei >> >

July 30, 2010

Re: [Pharo-project] SqueakSSL fails...

by Andrei Stebakov

Well, I put it there when Pharo was running. Now that I restarted Pharo I got a different error: When I execute "WebClient httpGet: 'https://www.google.com/search?q=squeak'." I got: ReadStream(Object)>>doesNotUnderstand: #readInto:startingAt:count: SecureSocketStream>>receiveDataInto:startingAt: SecureSocketStream>>receiveAvailableData SecureSocketStream(SocketStream)>>upToAll: WebResponse>>readFrom: WebClient>>sendRequest:content:size: WebClient>>sendRequest: WebClient>>httpGet:do: WebClient>>httpGet: WebClient class>>httpGet: UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: [] in TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection BlockClosure>>on:do: TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection TextMorphForShoutEditor(ParagraphEditor)>>doIt [] in TextMorphForShoutEditor(ParagraphEditor)>>doIt: TextMorphForShoutEditor(ParagraphEditor)>>terminateAndInitializeAround: TextMorphForShoutEditor(ParagraphEditor)>>doIt: TextMorphForShoutEditor(ParagraphEditor)>>dispatchOnKeyEvent:with: On Fri, Jul 30, 2010 at 4:47 PM, Andrei Stebakov <lispercat(a)gmail.com> wrote: > I've downloaded the SqueakSSL.dll plugin and put it in the root folder. > Also I've downloaded > SqueakSSL-Core > SqueakSSL-Plugin > SqueakSSL-Tests > > All tests passed. > Now when I try to execute "SqueakSSL google: 'Squeak'." > It fails creating the module in > > primitiveSSLCreate > Â Â Â Â "Primitive. Creates and returns a new SSL handle" > > Â Â Â Â <primitive: 'primitiveCreate' module: 'SqueakSSL'> > Â Â Â Â ^self primitiveFailed > > How can I fix it? > > Thank you, > Andrei >

July 30, 2010

Re: [Pharo-project] [squeak-dev] [ANN] Magma 1.1r2

by Chris Muller

> Good, I will base the configuration packages version number on this sar. > It will be named 1.1r2 or will be 1.1r3 (due to the deletion of a test > in the package you mentioned before, maybe isn't big enough to deserve a > new release and it was a "hurry" release maybe can we consider this a > typo and consider the sar the official 1.1r2 release) Yes, it was just the removal of one test, so please stay with 1.1r2. I'm pretty certain it's not going to affect any of the millions of folks who have downloaded Magma since yesterday... :)

July 30, 2010

[Pharo-project] running Magma tests in 1.1

by Chris Muller

To run the test-suite for Magma 1.1r2 in Pharo: - Proceed past two warnings about "FlapTab" when loading Magma. - Revert FileDirectory>>#fileExists: to the prior version. - Remove #testClassSchemaUpgrades. - Load OSProcess. The second and third steps, above, I believe may be regressions in Pharo 1.1. In Pharo 1.1: FileDirectory default fileExists: '/bin/sh' "---> false" but the file does, indeed, exist as a soft-link. Squeak answers true and, I'll bet, so does Pharo 1.0, so I'm not sure if there is a problem here or not. #testClassSchemaUpgrades tests Magma's ability to keep up with class-schema changes in the image. Usually class-schemas change only in development, not production systems so maybe it's not a big deal. But still, it can be very convenient develop new class schemas while connected to a persistent Magma store. Magma makes use of the SystemChangeNotifier to do this. I don't know if Pharo cleaned something with SystemChangeNotifier or a regression happened, but I don't have time to debug it right now. Certainly, if there is a problem with Magma I will fix it, but I'm not convinced of that yet. - Chris

July 30, 2010

Re: [Pharo-project] [squeak-dev] [ANN] Magma 1.1r2

by Miguel Enrique CobÃ¡ MartÃnez

El vie, 30-07-2010 a las 15:55 -0500, Chris Muller escribiÃ³: > Hi, > > >> 'Ma files additions-cmm.13.mcz'. > > > > This is a new package. What other package depends on it? > > The #fullBackupTo: method in Magma server uses a MaClientProcess, a > Process-wrapper that can broadcasts its progress, among other things. > MaClientProcess is part of the "Ma contextual search" package, which > depends on "Ma files additions" for its use of the #directoryTreeDo: > method (for something else unrelated to Magma). The "Ma" suite of > packages do serve several projects, not just Magma, even if some > methods seem to be "unused" from Magma's perspective. Ok. I will update the dependency graph of the ConfigurationOfMagma with this info. > > > Why on MagmaTester? I thought that for released versions, they were > > always on Magma repository and that MagmaTester was for your beta and > > not released yet versions, isn't that true anymore? > > It is still true. My objective was to get something out as quickly as > possible to try to accommodate the Pharo release schedule. I always > start at "Magma tester" I have now copied them to the other > repository. Thanks for your continued assistance on the Pharo side of > things. > > BTW: note there is an updated version of Magma tester which removed > an old unused test. Perfect. I will release a new ConfigurationOfMagma with support for this new version 1.1r2 with packages taken all from Magma repo in squeaksource. > > > In repository squeaksource.com/WriteBarrier, there are packages: > > > > WriteBarrier-tbn.28.mcz > > WriteBarrier-cmm.27.mcz > > > > Then in MagmaTester repository there is > > > > WriteBarrier-cmm.28.mcz > > > > and in Magma there is > > > > WriteBarrier-pmm.26.mcz > > The correct one to use is WriteBarrier-cmm.28.mcz. I do not have > update access to the "WriteBarrier" project on SqueakSource. Perhaps > Phillip will let me have access or copy it there for me? Please Phillipe, +1 to adding Chris to the developers of WriteBarrier as Magma is a main user of WriteBarrier. This way the last version will be on WriteBarrier repo (authoritative) and copied also in Magma repo (in case WriteBarrier disappear someday). > > I had tried to use WriteBarrier-tbn.28.mcz but there were still > underscore assignments in there. Therefore, since I had to "do some > work" anyway, I went ahead and reverted back to cmm.27, got out the > trusty ol'e FixUnderscores package, since it works and also preserves > the accounting information which, as you know, is important to me. > > > So I don't understand either, what is the policy here. Is the package > > modified, and pushed to the original repo (WriteBarrier) and *then* > > copied to MagmaTester and Magma or > > The rate of Magma releases has slowed considerably because it has been > stable and I've been working on other projects that employ Magma > lately rather than working very much on Magma itself. So I might like > at some point to retire "MagmaTester"; delete it. Feedback is > appreciated. > I vote for deleting it, because every released version is on Magma repo (I think) so there is less noise and less mistakes having some packages in one repo and others in other that form a release. > > I have prepared an update to the configuration of Magma for 1.1r2 with > > the preferences corrected but I would like to have all the packages in > > WriteBarrier and in Magma (that I consider the releases repositories, or > > at least, everything on Magma so that the configuration doesn't refer to > > MagmaTester altogether). What do you think? > > OK, I've copied them to "Magma" too. I will upload the SAR file to > SqueakMap too, soonish. Good, I will base the configuration packages version number on this sar. It will be named 1.1r2 or will be 1.1r3 (due to the deletion of a test in the package you mentioned before, maybe isn't big enough to deserve a new release and it was a "hurry" release maybe can we consider this a typo and consider the sar the official 1.1r2 release) Thanks for the answers > > - Chris > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma -- Miguel CobÃ¡ http://miguel.leugim.com.mx

July 30, 2010

Re: [Pharo-project] [squeak-dev] [ANN] Magma 1.1r2

by Chris Muller

Hi, >> 'Ma files additions-cmm.13.mcz'. > > This is a new package. What other package depends on it? The #fullBackupTo: method in Magma server uses a MaClientProcess, a Process-wrapper that can broadcasts its progress, among other things. MaClientProcess is part of the "Ma contextual search" package, which depends on "Ma files additions" for its use of the #directoryTreeDo: method (for something else unrelated to Magma). The "Ma" suite of packages do serve several projects, not just Magma, even if some methods seem to be "unused" from Magma's perspective. > Why on MagmaTester? I thought that for released versions, they were > always on Magma repository and that MagmaTester was for your beta and > not released yet versions, isn't that true anymore? It is still true. My objective was to get something out as quickly as possible to try to accommodate the Pharo release schedule. I always start at "Magma tester" I have now copied them to the other repository. Thanks for your continued assistance on the Pharo side of things. BTW: note there is an updated version of Magma tester which removed an old unused test. > In repository squeaksource.com/WriteBarrier, there are packages: > > WriteBarrier-tbn.28.mcz > WriteBarrier-cmm.27.mcz > > Then in MagmaTester repository there is > > WriteBarrier-cmm.28.mcz > > and in Magma there is > > WriteBarrier-pmm.26.mcz The correct one to use is WriteBarrier-cmm.28.mcz. I do not have update access to the "WriteBarrier" project on SqueakSource. Perhaps Phillip will let me have access or copy it there for me? I had tried to use WriteBarrier-tbn.28.mcz but there were still underscore assignments in there. Therefore, since I had to "do some work" anyway, I went ahead and reverted back to cmm.27, got out the trusty ol'e FixUnderscores package, since it works and also preserves the accounting information which, as you know, is important to me. > So I don't understand either, what is the policy here. Is the package > modified, and pushed to the original repo (WriteBarrier) and *then* > copied to MagmaTester and Magma or The rate of Magma releases has slowed considerably because it has been stable and I've been working on other projects that employ Magma lately rather than working very much on Magma itself. So I might like at some point to retire "MagmaTester"; delete it. Feedback is appreciated. > I have prepared an update to the configuration of Magma for 1.1r2 with > the preferences corrected but I would like to have all the packages in > WriteBarrier and in Magma (that I consider the releases repositories, or > at least, everything on Magma so that the configuration doesn't refer to > MagmaTester altogether). What do you think? OK, I've copied them to "Magma" too. I will upload the SAR file to SqueakMap too, soonish. - Chris

July 30, 2010

[Pharo-project] SqueakSSL fails...

by Andrei Stebakov

I've downloaded the SqueakSSL.dll plugin and put it in the root folder. Also I've downloaded SqueakSSL-Core SqueakSSL-Plugin SqueakSSL-Tests All tests passed. Now when I try to execute "SqueakSSL google: 'Squeak'." It fails creating the module in primitiveSSLCreate "Primitive. Creates and returns a new SSL handle" <primitive: 'primitiveCreate' module: 'SqueakSSL'> ^self primitiveFailed How can I fix it? Thank you, Andrei

July 30, 2010

Re: [Pharo-project] help with Glamour

by Felipe Ignacio Valverde Campos

nice, that works :) ! we are using Glamour on AspectMaps (http://www.squeaksource.com/AspectMaps.html) for the main UI and another to import projects (Java and AspectJ) on Moose in order to visualize using Mondrian more information on http://pleiad.cl/research/software/aspectmaps thanks for the help and tips ! El jue, 29-07-2010 a las 07:58 +0200, Tudor Girba escribiÃ³: > Hi Felipe, > > The result of opening a browser is a window. > > So, you could use something like this: > > browser := GLMTabulator new. > ... > window := browser openOn: ... > window maximize. > ... > window delete. > > > Could I ask in what context you are using Glamour? Also, a better > forum for discussing these issues is the moose-dev mailing list: > - address: moose-dev(a)iam.unibe.ch > - registration: https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > Cheers, > Doru > > > On 28 Jul 2010, at 21:04, Alexandre Bergel wrote: > > > Hi Felipe, > > > > No idea, but this is good to see you here! > > > > Alexandre > > > > > > On 28 Jul 2010, at 18:47, Felipe Ignacio Valverde Campos wrote: > > > >> Hi, i'm beginner on this tools, so i need your help please :) > >> i have some doubts about Glamour, specificaly with GLMTabulator. > >> > >> how can i set the window size ? > >> and how can i close it without pressing the X ? > >> > >> thanks > >> -- > >> http://www.dcc.uchile.cl/~fvalverd/public_key.asc > >> Estudiante de IngenierÃa Civil en ComputaciÃ³n. > >> Facultad de Ciencias FÃsicas y MatemÃ¡ticas. > >> Universidad de Chile. > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://www.dcc.uchile.cl/~fvalverd/public_key.asc Estudiante de IngenierÃa Civil en ComputaciÃ³n. Facultad de Ciencias FÃsicas y MatemÃ¡ticas. Universidad de Chile.

July 30, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Eliot Miranda

On Fri, Jul 30, 2010 at 11:55 AM, Martin McClure <martin(a)hand2mouse.com>wrote: > On 07/30/2010 11:28 AM, Eliot Miranda wrote: > > [...] > > > >> Excellent!! Just by curious, your idea, or what you did in VW, was >> to be able to put SmallFloats directly inside the address ? just >> like we do nowadays with SmallInteger ? >> >> >> Yes. The scheme provides IEEE double precision but with a smaller >> exponent so the range is the same as the 32-bit single-precision range. >> i.e. 3 bits are used as tag bits to distinguish SmallInteger >> SmallFloat Character and objects. That leaves 1 bit for sign, 52 bits >> for the mantissa and 8 bits for the exponent. The use of 3 tag bits >> comes from 64-bit pointers being 8-byte aligned and so having the least >> significant 3 bits 0. I don't want to defend that choice now just to >> give you a flavour of the representation: >> >> | 8-bit exponent | 52 bit mantissa | sign | tags | >> > > A few more words on the VW SmallDouble implementation: We also use this > representation in GemStone; it works very well. > > This representation exactly represents a subset of the possible IEEE > doubles. It's the "common" 1/8th of the total range, with the addition of > +-0.0. Non-zero numbers very close to zero or very far from zero overflow to > normal Float objects in a manner very similar to the way > SmallInteger/LargeInteger work. The infinities and NaNs also must be > represented as normal Floats. > > Because between SmallDouble and Float all IEEE doubles can be represented, > all floating-point computations give the correct (per IEEE) result, but you > save memory and computation is generally faster because you don't access as > many bytes in main memory. > and I should say that while I came up with the scheme it was Martin who very patiently debugged it. Without Martin's help it would have been a train wreck. Thanks again, Martin! > Regards, > > -Martin >

July 30, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Martin McClure

On 07/30/2010 11:28 AM, Eliot Miranda wrote: [...] > > Excellent!! Just by curious, your idea, or what you did in VW, was > to be able to put SmallFloats directly inside the address ? just > like we do nowadays with SmallInteger ? > > > Yes. The scheme provides IEEE double precision but with a smaller > exponent so the range is the same as the 32-bit single-precision range. > i.e. 3 bits are used as tag bits to distinguish SmallInteger > SmallFloat Character and objects. That leaves 1 bit for sign, 52 bits > for the mantissa and 8 bits for the exponent. The use of 3 tag bits > comes from 64-bit pointers being 8-byte aligned and so having the least > significant 3 bits 0. I don't want to defend that choice now just to > give you a flavour of the representation: > > | 8-bit exponent | 52 bit mantissa | sign | tags | A few more words on the VW SmallDouble implementation: We also use this representation in GemStone; it works very well. This representation exactly represents a subset of the possible IEEE doubles. It's the "common" 1/8th of the total range, with the addition of +-0.0. Non-zero numbers very close to zero or very far from zero overflow to normal Float objects in a manner very similar to the way SmallInteger/LargeInteger work. The infinities and NaNs also must be represented as normal Floats. Because between SmallDouble and Float all IEEE doubles can be represented, all floating-point computations give the correct (per IEEE) result, but you save memory and computation is generally faster because you don't access as many bytes in main memory. Regards, -Martin

July 30, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Tudor Girba

Hi, I can give a hand in testing on Mac as I am using it everyday. Cheers, Doru On 30 Jul 2010, at 05:26, Serge Stinckwich wrote: > 2010/7/29 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Hi folks. Hope Eliot is reading this thread. >> >> It is time to think in Pharo 1.2 and we need to discuss if we want >> to have >> CogVM as the standard Pharo VM. > > Thank you Mariano this important issue for the future of Pharo. > >> Most of us have tried it and found it incredible fast. So it would >> be very >> good to take advantage of it. But I think there are a couple of >> things to >> be discussed: >> >> 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot >> quotes: >> "The Cog VM is a just-in-time compiler that currently supports only >> x86 >> >> No effort has been made to maintain 64-bit compatibility. >> Apologies, this >> was unaffordable." >> >> So...how much important is this for us? do we care? and if we want >> to do it, >> is it "doable" ? is it less doable than the normal squeak VM ? >> >> I really would like to have 64bits VM + 64bits images in a near >> future...but >> hat's just my thoguhts. >> >> 2) The status of the external plugins. Are they working with Cog ? >> Not only >> the "core plugings" but FFI, OSProcess (I read some problems with >> it), >> TrueType, etc... >> >> 3) Is it stable for production use? For example, I read that with >> seaside >> there are some crashes. > > For crashed related to socket, i know that Noury and Luc are working > on a new implementation of sockets, so maybe if it is ready it could > be included in 1.2 version. > >> 4) Depends on heroes. I never liked this idea. It has nothing to do >> with >> Eliot. He is very cool and helpful. But I wonder, do we understand >> the new >> VM and the changes? are we able to handle and fix it even without >> eliot ? >> >> 5) Integration to VMMaker. I saw that they started to merge cog >> (actually, I >> think only stack vm?) to the trunk of VMMaker. This is really good >> news. I >> hope everything is there and merged. >> >> 6) Binaries. It seems the official released didn't come with >> binaries. So we >> should compile it for each OS. > > I think both binaries should be provided for 1.2 and also OneClick > images with standard and Cog VM, in order to maximize > the number of tests for the new VM. If we really want to push this, > someone should take care of all of this. > > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Don't give to get. Just give."

July 30, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Eliot Miranda

2010/7/30 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/7/29 Eliot Miranda <eliot.miranda(a)gmail.com> > > >> >> 2010/7/29 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >> Hi folks. Hope Eliot is reading this thread. >>> >> >> Yes, I'm reading :) >> > > > THanks Eliot for all the answers. It seems they are all good news :) > > >> >> >>> It is time to think in Pharo 1.2 and we need to discuss if we want to >>> have CogVM as the standard Pharo VM. >>> >>> Most of us have tried it and found it incredible fast. So it would be >>> very good to take advantage of it. But I think there are a couple of things >>> to be discussed: >>> >>> 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot >>> quotes: >>> "The Cog VM is a just-in-time compiler that currently supports only x86 >>> >> >> It is only initially aimed at x86. That's the most important platform by >> far from Teleplace's perspective and I suspect the majority of the community >> is on x86. But Cog was designed form the outset to be portable. The Cogit >> is architected to support other ISAs. See CogAbstractInstruction and its >> one subclass CogIA32Compiler. To port to another ISA you should >> subclass CogAbstractInstruction and implement the same protocol >> as CogIA32Compiler. >> >> I would love to see a CogARMCompiler and a CogPPCCompiler and encourage >> anyone with low-level expertise on those platforms to have a go. I'm always >> here to answer questions. >> >> >> > This is great Eliot. I thought that Cog was completly aimed to x86 and > that would be difficult to port. That was my concern, but now with what you > said it is much clear :) > > > > >> No effort has been made to maintain 64-bit compatibility. Apologies, this >>> was unaffordable." >>> >>> So...how much important is this for us? do we care? and if we want to do >>> it, is it "doable" ? is it less doable than the normal squeak VM ? >>> >>> I really would like to have 64bits VM + 64bits images in a near >>> future...but hat's just my thoguhts. >>> >> >> I'm also thinking abut 64-bits but want to do 64-bits with a new object >> representation based on my 64-bit objrep for VisualWorks, which would >> include SmallFloat. Realistically this is a year out, because the 32-bit >> version of the new objrep and the pinning GC need to be implemented before >> I'll be able to do a 64-bit VM. But it's an obvious and logical direction >> to go in. >> > > > Excellent!! Just by curious, your idea, or what you did in VW, was to be > able to put SmallFloats directly inside the address ? just like we do > nowadays with SmallInteger ? > Yes. The scheme provides IEEE double precision but with a smaller exponent so the range is the same as the 32-bit single-precision range. i.e. 3 bits are used as tag bits to distinguish SmallInteger SmallFloat Character and objects. That leaves 1 bit for sign, 52 bits for the mantissa and 8 bits for the exponent. The use of 3 tag bits comes from 64-bit pointers being 8-byte aligned and so having the least significant 3 bits 0. I don't want to defend that choice now just to give you a flavour of the representation: | 8-bit exponent | 52 bit mantissa | sign | tags | > >> 2) The status of the external plugins. Are they working with Cog ? Not >>> only the "core plugings" but FFI, OSProcess (I read some problems with it), >>> TrueType, etc... >>> >> >> ReentrantFFIPlugin (a.k.a. src/plugins/SqueakFFIPrims/SqueakFFIPrims.c) >> should work. But people need to build and test. >> >> 3) Is it stable for production use? For example, I read that with seaside >>> there are some crashes. >>> >> >> Well, it is the production VM at Teleplace so at least for one context the >> answer is certainly yes. There must be something obviously broken with >> sockets (is it all platforms or only linux?) because we use sockets >> intensively at Teleplace and only see problems on a single customer's >> machine which looks to be to do with virus protection. I'm on holiday next >> week and am rather busy right now, but perhaps later in August I can work >> with Lukas to try and sort out the socket issues. >> > > ok... > > >> >> 4) Depends on heroes. I never liked this idea. It has nothing to do with >>> Eliot. He is very cool and helpful. But I wonder, do we understand the new >>> VM and the changes? are we able to handle and fix it even without eliot ? >>> >> >> THis is a serious issue. I need to be nagged to document the system on my >> blog. I mean to get to this (perhaps in September?). Alas a Smalltalk JIT >> is a complex beast, significantly more complex than the interpreter, and is >> not the easiest thing to understand or debug. So even if it is well >> documented it'll be more difficult to fix than the interpreter, but that's a >> price one has to pay for this kind of performance. >> >> > > I agree. That's why my concern. > > > >> >>> 5) Integration to VMMaker. I saw that they started to merge cog >>> (actually, I think only stack vm?) to the trunk of VMMaker. This is really >>> good news. I hope everything is there and merged. >>> >> >> Cog is a fork of VMMaker. We may be able to merge at some stage, and >> Cog's Slang should still work with the old Interpreter. But for now, >> inevitably, it's a fork. I needed to add a lot of functionality to Slang to >> write Cog, and I didn't have the cycles to keep Interpreter up to date. >> That's life :) >> >> > ok > > > >> 6) Binaries. It seems the official released didn't come with binaries. So >>> we should compile it for each OS. >>> >> >> There is /no/ official release. Until Cog has stabilized and the VM >> maintainers have taken it up it's definitely unoffficial :) >> > > Ok...forget the "official" word....where should we get the sources (svn) > and the VMMaker code in order to compile the latest and build binaries? > > > >> >> Ok..that's all my thoughts. I would really like to have a discussion here >>> and see what to do.....grrrrrr you are all in holidays, aren't you? hahah >>> >> >> two days to go :) >> > > > enjoy ;) > > > >> >> >>> >>> cheers >>> >>> Mariano >>> >> >> best >> Eliot >> >> >>> >>> _______________________________________________ >>> 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 30, 2010

Re: [Pharo-project] cog-based image crashes on mac

by Mariano Martinez Peck

I have a similar problem, with the latest svn version, 2249. (localPrimIndex > 255) && (localPrimIndex < 520) 15376 squeak: could not load plugin `SocketPlugin' [Switching to process 26735] nanosleep: Invalid argument But it is not random. It happens everytime I try to run PharoCore 12069 tests. Cheers MAriano On Mon, Jul 26, 2010 at 8:43 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > 2010/7/26 Eliot Miranda <eliot.miranda(a)gmail.com>: > > There's an update in svn that could fix crashes. > > No sorry, still the same (if I remember correctly I've never seen the > bunch of error messages before the last two though) with the latest > svn code: > > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] > mprotect(x,y,PROT_READ > | PROT_WRITE): Cannot allocate memory > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] > mprotect(x,y,PROT_READ > | PROT_WRITE): Invalid argument > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `MiscPrimitivePlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `DropPlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `FilePlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `SecurityPlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `BitBltPlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `LargeIntegers' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `B2DPlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `InternetConfigPlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `SocketPlugin' > 26.07.10 20:40:03 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `DSAPrims' > 26.07.10 20:40:06 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `JPEGReadWriter2Plugin' > 26.07.10 20:41:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] nanosleep: Invalid > argument > 26.07.10 20:41:33 > com.apple.launchd.peruser.501[200] > ([0x0-0x1d3dd3c].com.teleplace.Teleplace[4514]) > Exited with exit code: 1 > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 30, 2010

[Pharo-project] About overlapping packages :(

by StÃ©phane Ducasse

Hi I have worked on the integration of the new package implementation and its synchronisation with MC/PackageInfo. Now I have the following problem: Scenario 1: the user have created a package Foo which contains several classes, some like FooObject in the category Foo-Core, others in category Foo-Others. Now if he creates a package Foo-Core, Foo-Core should contain the classes having Foo-Core as category. I have a problem with PackageInfo semantics since here packages Foo and Foo-Core could contain FooObject. Scenario 2: the user have created a class in the category Foo-Core, and after created a package only named Foo. The classes in category Foo-Core should be added to Foo. But some other packages and categories starting with Foo may exist. Now in the new implementation, classes cannot be two packages at the same time. So I will be forced to implement a checker making sure that there is no such situation and also that we should remove first the Foo package and then create two package Foo-Core and Foo-Others. What do you think? May be such a checker should be hooked into MC right now so we detect anyway such bad situations. For the moment I'm fighting within events and announcements to make sure that I could potentially keep the new implementation of Package and PackageOrganizer in sync with PackageInfo but this is not that simple. Stef

July 30, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Mariano Martinez Peck

2010/7/29 Eliot Miranda <eliot.miranda(a)gmail.com> > Hi Lukas, > > On Thu, Jul 29, 2010 at 2:00 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot >> quotes: >> > "The Cog VM is a just-in-time compiler that currently supports only x86 >> >> So far I never felt the need for 64-bit images. >> >> > 3) Is it stable for production use? For example, I read that with >> seaside >> > there are some crashes. >> >> Seaside itself is not the problem, Eliot quickly fixed the remaining >> issues with Continuations shortly after the open-source release of >> Cog. > > > and I still need to fix objects-as-methods but have no time right now. > That's probably two to five days work to do right :/ > > Although it is very important for us, it is not that we needed right NOW. Take all the time you need. It is good to see you want to fix it :) > > >> The problem are the sockets, they cause frequent random crashes >> of the VM. >> > > Do we have any more specific information on these socket-related crashes? > (platform, crash reports, test cases, etc?) > That's the idea of the Pharo OneClick with Cog. We can distribute that so that everybody can start to play with it and report problem. But for that, we need to know where to get all Cog sources, and how to compile it. In addition, what kind of flags in configure would help you to debug problems and get as much information as possible. With this we can distribute a VM + image that logs as much as possible. This one click would be experimental, not production. Thus, it shouldn't care if it is a little slower (because of the logging). Cheers Mariano > > best > Eliot > > >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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 30, 2010

[Pharo-project] about ToolBuilder

by stephane ducasse

Hi guys during the sprint I discussed with Gary about ToolBuilder and we think that it would be better to remove it since a lot of new widgets are not covered so this means that we will be constantly limiting ourselves. Of course ToolBuilder is a nice idea (if we would have several UI framework). So far we got only one and we would have several we would have to take the smallest common denominator. Another idea would be to extend toolBuilder to support new widgets. So what do you think? Stef

July 30, 2010

[Pharo-project] How to remove Monticello?

by Hilaire Fernandes

Dear all, I tried this: (MCPackage named: 'MonticelloGUI') unload. (MCPackage named: 'MonticelloConfiguration') unload. (MCPackage named: 'Monticello') unload. but the third line did not work. Any experiences to share on that topic? Thanks Hilaire

July 30, 2010

Re: [Pharo-project] [Pharo-users] Recent Messages Browser

by Mariano Martinez Peck

On Fri, Jul 30, 2010 at 2:47 AM, Benjamin Van Ryseghem < benjamin.vanryseghem(a)gmail.com> wrote: > Hi everybody, > > > I've rewrited a recent messages browser based on MorphTreeMorph. > > Hi, this is very good idea! > If you can test it and tell me what's do you think about, it will be cool > (I'm a new Smalltalker ^^) > > welcome! > You can download code here : > > Gofer new > squeaksource: 'PharoTaskForces'; > package: 'RecentSubmissions'; > load. > > > To launch it, just click on the World >> Tools >> Recent Messages. > > You can set it up in the Setting Menu >> Code browsing >> Recent Message. > > > Ok...I did it. A few remarks: 1) RecentMessageList >> initialize you do SmalltalkImage current addToStartUpList: self class. but should be SmalltalkImage addToStartUpList: self class. (at least in Pharo 1.1) 2) What is the idea of the Recent Messages? To see the recent MODIFIED methods ? isn't it? If true, maybe would be good to 2.1) directly show the diff with the previous version 2.2) Have a button to see the versions of that method 3) Once you press any button, like collapse all or similar, they become blue and neve grey again 4) When is the list of recen messages clean ? how do you know the recen messages? you store that information somewhere? when is that cleaned? Thank you very much and continue with the good work! Maybe once we can include it by defult in Pharo. Cheers Mariano > > Thank you > > > > Ben > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >

July 30, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Mariano Martinez Peck

2010/7/29 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/7/29 Mariano Martinez Peck <marianopeck(a)gmail.com> > > Hi folks. Hope Eliot is reading this thread. >> > > Yes, I'm reading :) > THanks Eliot for all the answers. It seems they are all good news :) > > >> It is time to think in Pharo 1.2 and we need to discuss if we want to have >> CogVM as the standard Pharo VM. >> >> Most of us have tried it and found it incredible fast. So it would be very >> good to take advantage of it. But I think there are a couple of things to >> be discussed: >> >> 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot >> quotes: >> "The Cog VM is a just-in-time compiler that currently supports only x86 >> > > It is only initially aimed at x86. That's the most important platform by > far from Teleplace's perspective and I suspect the majority of the community > is on x86. But Cog was designed form the outset to be portable. The Cogit > is architected to support other ISAs. See CogAbstractInstruction and its > one subclass CogIA32Compiler. To port to another ISA you should > subclass CogAbstractInstruction and implement the same protocol > as CogIA32Compiler. > > I would love to see a CogARMCompiler and a CogPPCCompiler and encourage > anyone with low-level expertise on those platforms to have a go. I'm always > here to answer questions. > > > This is great Eliot. I thought that Cog was completly aimed to x86 and that would be difficult to port. That was my concern, but now with what you said it is much clear :) > No effort has been made to maintain 64-bit compatibility. Apologies, this >> was unaffordable." >> >> So...how much important is this for us? do we care? and if we want to do >> it, is it "doable" ? is it less doable than the normal squeak VM ? >> >> I really would like to have 64bits VM + 64bits images in a near >> future...but hat's just my thoguhts. >> > > I'm also thinking abut 64-bits but want to do 64-bits with a new object > representation based on my 64-bit objrep for VisualWorks, which would > include SmallFloat. Realistically this is a year out, because the 32-bit > version of the new objrep and the pinning GC need to be implemented before > I'll be able to do a 64-bit VM. But it's an obvious and logical direction > to go in. > Excellent!! Just by curious, your idea, or what you did in VW, was to be able to put SmallFloats directly inside the address ? just like we do nowadays with SmallInteger ? > > 2) The status of the external plugins. Are they working with Cog ? Not >> only the "core plugings" but FFI, OSProcess (I read some problems with it), >> TrueType, etc... >> > > ReentrantFFIPlugin (a.k.a. src/plugins/SqueakFFIPrims/SqueakFFIPrims.c) > should work. But people need to build and test. > > 3) Is it stable for production use? For example, I read that with seaside >> there are some crashes. >> > > Well, it is the production VM at Teleplace so at least for one context the > answer is certainly yes. There must be something obviously broken with > sockets (is it all platforms or only linux?) because we use sockets > intensively at Teleplace and only see problems on a single customer's > machine which looks to be to do with virus protection. I'm on holiday next > week and am rather busy right now, but perhaps later in August I can work > with Lukas to try and sort out the socket issues. > ok... > > 4) Depends on heroes. I never liked this idea. It has nothing to do with >> Eliot. He is very cool and helpful. But I wonder, do we understand the new >> VM and the changes? are we able to handle and fix it even without eliot ? >> > > THis is a serious issue. I need to be nagged to document the system on my > blog. I mean to get to this (perhaps in September?). Alas a Smalltalk JIT > is a complex beast, significantly more complex than the interpreter, and is > not the easiest thing to understand or debug. So even if it is well > documented it'll be more difficult to fix than the interpreter, but that's a > price one has to pay for this kind of performance. > > I agree. That's why my concern. > >> 5) Integration to VMMaker. I saw that they started to merge cog (actually, >> I think only stack vm?) to the trunk of VMMaker. This is really good news. I >> hope everything is there and merged. >> > > Cog is a fork of VMMaker. We may be able to merge at some stage, and Cog's > Slang should still work with the old Interpreter. But for now, inevitably, > it's a fork. I needed to add a lot of functionality to Slang to write Cog, > and I didn't have the cycles to keep Interpreter up to date. That's life :) > > ok > 6) Binaries. It seems the official released didn't come with binaries. So >> we should compile it for each OS. >> > > There is /no/ official release. Until Cog has stabilized and the VM > maintainers have taken it up it's definitely unoffficial :) > Ok...forget the "official" word....where should we get the sources (svn) and the VMMaker code in order to compile the latest and build binaries? > > Ok..that's all my thoughts. I would really like to have a discussion here >> and see what to do.....grrrrrr you are all in holidays, aren't you? hahah >> > > two days to go :) > enjoy ;) > > >> >> cheers >> >> Mariano >> > > best > Eliot > > >> >> _______________________________________________ >> 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 30, 2010

Re: [Pharo-project] Pharo 1.1 host menu os x

by Mariano Martinez Peck

2010/7/30 laurent laffont <laurent.laffont(a)gmail.com> > On Thu, Jul 29, 2010 at 11:52 PM, Michael Roberts <mike(a)mjr104.co.uk>wrote: > >> I gave the latest release a spin and it seams quit doesn't work (again). >> old reference -> >> http://code.google.com/p/pharo/issues/detail?id=1068 >> >> can someone confirm? if so do we want a new issue or reopen the old one? >> >> Also the host menu is not consistent with the world menu. for example >> the tools menu is different. Script manager is in one but not the >> other. The help browser text references it which is why i noticed. I >> haven't looked at the implementation. is there a way they are supposed >> to be kept in sync? >> > > I've once fixed it. Look at HostSystemMenusMacOSX, building-menus protocol. > I rarely use MacOSX so can you check ? > Ok...I did it. But...addToolsMenu calls self openMenu and openMenu calls ToolSet menuItems. which is hardcoded, and not using pragmas. And this is why for example, ScriptManager doesn't appear in the HOstMenu So yes...I think we should open an issue :) CHeers > > Cheers, > > Laurent > > > >> >> cheers, >> Mike >> >> _______________________________________________ >> 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 30, 2010

Re: [Pharo-project] Pharo 1.1 host menu os x

by Mariano Martinez Peck

On Thu, Jul 29, 2010 at 11:52 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > I gave the latest release a spin and it seams quit doesn't work (again). > old reference -> > http://code.google.com/p/pharo/issues/detail?id=1068 > > can someone confirm? if so do we want a new issue or reopen the old one? > > Michael, it is working for me. Not only in the OneClick but also with the image and the Squeak 4.2.5beta1U what is exactly what it is NOT working for you? > Also the host menu is not consistent with the world menu. yes, this is true. > for example > the tools menu is different. Script manager is in one but not the > other. The help browser text references it which is why i noticed. I > haven't looked at the implementation. is there a way they are supposed > to be kept in sync? > > maybe both should use the pragmas now? > cheers, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 30, 2010

Re: [Pharo-project] Request for test

by Hilaire Fernandes

Thanks to all of you for your feedback. Le 30/07/2010 05:45, Serge Stinckwich a Ã©crit : > The application icon is looking like a triangle and the UI is in > french on my mac. > Are the translations available somewhere online ? https://gforge.inria.fr/scm/viewvc.php/drgeo2/i18n/po/?root=istoa Hilaire

July 30, 2010

Re: [Pharo-project] [squeak-dev] [ANN] Magma 1.1r2

by Miguel Enrique CobÃ¡ MartÃnez

Premature send El jue, 29-07-2010 a las 18:55 -0500, Chris Muller escribiÃ³: > I am pleased to announce a new release of Magma containing my updates > since 1.1r1: - All underscore assignments have now been updated to ANSI assignments. Very Good! > 'Ma files additions-cmm.13.mcz'. This is a new package. What other package depends on it? > > These package versions are available in the "MagmaTester" project of > squeaksource.com. > Why on MagmaTester? I thought that for released versions, they were always on Magma repository and that MagmaTester was for your beta and not released yet versions, isn't that true anymore? In repository squeaksource.com/WriteBarrier, there are packages: WriteBarrier-tbn.28.mcz WriteBarrier-cmm.27.mcz Then in MagmaTester repository there is WriteBarrier-cmm.28.mcz and in Magma there is WriteBarrier-pmm.26.mcz So I don't understand either, what is the policy here. Is the package modified, and pushed to the original repo (WriteBarrier) and *then* copied to MagmaTester and Magma or Is the package modified in your MagmaTester repo and when finished, copied to original repo (WriteBarrier) and releases repo (Magma) I have prepared an update to the configuration of Magma for 1.1r2 with the preferences corrected but I would like to have all the packages in WriteBarrier and in Magma (that I consider the releases repositories, or at least, everything on Magma so that the configuration doesn't refer to MagmaTester altogether). What do you think? Cheers and thanks for your work. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

July 30, 2010

Re: [Pharo-project] [squeak-dev] [ANN] Magma 1.1r2

by Miguel Enrique CobÃ¡ MartÃnez

El jue, 29-07-2010 a las 18:55 -0500, Chris Muller escribiÃ³: > I am pleased to announce a new release of Magma containing my updates > since 1.1r1: - All underscore assignments have now been updated to ANSI assignments. Very Good! > 'Ma files additions-cmm.13.mcz'. This is a new package. What other package depends on it? > > These package versions are available in the "MagmaTester" project of > squeaksource.com. > Why on MagmaTester? I thought that for released versions, they were always on Magma repository and that MagmaTester was for your beta and not released yet versions, isn't that true anymore? In repository squeaksource.com/WriteBarrier, there are packages: WriteBarrier-tbn.28.mcz WriteBarrier-cmm.27.mcz Then in MagmaTester repository there is WriteBarrier-cmm.28.mcz and in Magma there is -- Miguel CobÃ¡ http://miguel.leugim.com.mx

July 30, 2010

Re: [Pharo-project] PharoCore 1.1 comments

by Michael Roberts

> - SystemVersion current majorMinorVersion prints: > > PharoCore 1.0: 'PharoCore1.0' > > PharoCore 1.1: 'Pharo1.1' > the version object has been downgraded again. the version string needs to be nil and it keeps on getting broken. I will deprecate the mechanism once i recheck the package issues. Normally, you just set #type to make the images different. thanks, Mike

July 30, 2010

[Pharo-project] PharoCore 1.1 comments

by Miguel Enrique CobÃ¡ MartÃnez

Hi all, some things I noticed in PharoCore 1.1 release: - This PharoCore-1.1.zip doesn't include a sources file. It was good to have it included in the zip as before. Can be included for every PharoCore release? - The page says that PharoV10.sources is for use with 1.0, 1.1 and 1.2. Shouldn't be better to have a different one for each release? (even if 1.1 is a copy of 1.0, the different name avoids doubts about numbering scheme): PharoCore-1.0.image PharoCore-1.0.changes PharoV10.sources PharoCore-1.1.image PharoCore-1.1.changes PharoV10.sources (???) ... PharoCore-1.7.image PharoCore-1.7.changes PharoV10.sources (bigger ???) Just a suggestion. ;) - SystemVersion current majorMinorVersion prints: PharoCore 1.0: 'PharoCore1.0' PharoCore 1.1: 'Pharo1.1' Maybe this should be in the script preparing the image so that correctly set the version string for PharoCore images and for Pharo images (or maybe already is there but wasn't executed?) Other than that, the new image is *very* fast! Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

July 30, 2010

Re: [Pharo-project] Pharo 1.1 host menu os x

by laurent laffont

On Thu, Jul 29, 2010 at 11:52 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > I gave the latest release a spin and it seams quit doesn't work (again). > old reference -> > http://code.google.com/p/pharo/issues/detail?id=1068 > > can someone confirm? if so do we want a new issue or reopen the old one? > > Also the host menu is not consistent with the world menu. for example > the tools menu is different. Script manager is in one but not the > other. The help browser text references it which is why i noticed. I > haven't looked at the implementation. is there a way they are supposed > to be kept in sync? > I've once fixed it. Look at HostSystemMenusMacOSX, building-menus protocol. I rarely use MacOSX so can you check ? Cheers, Laurent > > cheers, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 30, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Serge Stinckwich

On Fri, Jul 30, 2010 at 1:29 AM, <csrabak(a)bol.com.br> wrote: > > Em 29/07/2010 03:10, laurent laffont < laurent.laffont(a)gmail.com > escreveu: > >> > On Â Wed, Â Jul Â 28, Â 2010 Â at Â 6:32 Â PM, Â Nicolas Â Cellier >> > Â wrote: >> > >> > > Once Â upon a Â time Â I wondered Â if Â it wouldn't Â be possible Â to >> > > Â translate the whole sources in any language (via a Dictionary). >> > > Â In Â any other language, Â we (think Â of a Â child) must Â learn to >> > > Â "talk' Â to Â computer Â in Â computer Â own Â language... Â So Â an >> > > Â apprentice has to learn a Â new language anyway Be it an english >> > > Â computer language is thus Â not that important. Â However, one of >> > > Â the nice Â properties of Smalltalk is enabling Â "talking" to the >> > > Â machine in a Â language close to our natural Â language, and that >> > > Â lowers Â the Â barriers. Â So Â the Â question Â of natural Â language >> > > Â naturally arises. >> > > >> > > 2010/7/28 Carla F. Â Griggio Â Well, that >> > Â last comment reminded me of Â something: I've read code written in >> > Â english by people that clearly didn't >> > know a lot of english, and it kept me weeks thinking that the code >> > did Â something Â that Â it Â didn't Â (and, of Â course, Â it Â was Â more >> > difficult >> > to Â realize why the Â code didn't Â behave like Â it was Â saying :P). >> > Â So... as writing everything in Â english can be a solution, it can >> > Â be a big problem too :( >> > >> Â And a lot (majority ?) of developpers don't want to use English, or >> don't Â understand Â English, Â or Â don't Â want to Â try Â to Â understand >> English, or don't have the courage to try to understand English. And >> they need to communicate their Â ideas / code with others developpers >> in the same position :) > > I think you're heading to a position I've already discussed several years > ago with Jecel (not surprisingly when he was teaching a tutorial on Smalltalk) > on the issue of non native English speakers 'lose' a bit of the user > friendliness of certain programming languages because they need to create a full > 'dictionary' in their heads about a certain programming concept and the > [foreign] language they need to memorize. Â He gave this example (IIRC): > > NNN FOR I=1 TO 120 NEXT I > > which for the Canadian boys he was accompanying they read as 'natural language', > whereas Brazilian children had to memorize that the 'tokens' "FOR" "TO" and > "NEXT" had to written in a certain syntax to create a loop in this language. > > The same happens in Smalltalk as most of the methods being in English, when > I. Tomek in his book or introductory paper mentions that it is natural to have > in Smalltalk: > > |rusty| > > rusty := Dog new. > > rusty bark. > > For a non native English speaker this syntax is tantamount to some obscure > mathematical notation. > >> Â I Â don't Â like Â writing Â in Â French, Â it's Â not Â suitable Â for >> programming. Have you ever Â seen WinDev code with auto-translation ? > > I cannot tell if it was successful or not but I remember in the seventies it > was reported that in France there was an attempt to translate to French the > COBOL keywords. Â Any account on the outcome of that? I dunno of the translation of COBOL in french, but i remember when i was in high school in the 80ies having using applications built in LSE (Language Symbolique d'Enseignement). It was a kind of BASIC written in french. More information here: http://en.wikipedia.org/wiki/LSE_%28programming_language%29 and in french here: http://fr.wikipedia.org/wiki/LSE_%28langage_de_programmation%29 I remember doing german lessons with LSE programs. One way to trick the programs was to stop the application, to look at the name of variable used to give the answer. After that everytime you replyed with the name of variable, every exercice was done right ! Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 30, 2010

Re: [Pharo-project] Request for test

by Serge Stinckwich

On Thu, Jul 29, 2010 at 8:38 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Dear all, > > I am preparing a DrGeo release. > > I will be very please if Windows and Mac user could test it for me please. > > I need to know if the application icon is looking like a triangle and if > DrGeo UI is in French for the French users. > > Here it is: http://people.ofset.org/hilaire/DrGeo.app.zip Great ! The application icon is looking like a triangle and the UI is in french on my mac. Are the translations available somewhere online ? Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 30, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Serge Stinckwich

2010/7/29 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi folks. Hope Eliot is reading this thread. > > It is time to think in Pharo 1.2 and we need to discuss if we want to have > CogVM as the standard Pharo VM. Thank you Mariano this important issue for the future of Pharo. > Most of us have tried it and found it incredible fast. So it would be very > good to take advantage of it.Â But I think there are a couple of things to > be discussed: > > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes: > "The Cog VM is a just-in-time compiler that currently supports only x86 > > No effort has been made to maintain 64-bit compatibility.Â Apologies, this > was unaffordable." > > So...how much important is this for us? do we care? and if we want to do it, > is it "doable" ?Â is it less doable than the normal squeak VM ? > > I really would like to have 64bits VM + 64bits images in a near future...but > hat's just my thoguhts. > > 2) The status of the external plugins. Are they working with Cog ?Â Not only > the "core plugings" but FFI, OSProcess (I read some problems with it), > TrueType, etc... > > 3) Is it stable for production use?Â For example, I read that with seaside > there are some crashes. For crashed related to socket, i know that Noury and Luc are working on a new implementation of sockets, so maybe if it is ready it could be included in 1.2 version. > 4) Depends on heroes. I never liked this idea. It has nothing to do with > Eliot. He is very cool and helpful. But I wonder, do we understand the new > VM and the changes? are we able to handle and fix it even without eliot ? > > 5) Integration to VMMaker. I saw that they started to merge cog (actually, I > think only stack vm?) to the trunk of VMMaker. This is really good news. I > hope everything is there and merged. > > 6) Binaries. It seems the official released didn't come with binaries. So we > should compile it for each OS. I think both binaries should be provided for 1.2 and also OneClick images with standard and Cog VM, in order to maximize the number of tests for the new VM. If we really want to push this, someone should take care of all of this. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 30, 2010

[Pharo-project] [ANN] Magma 1.1r2

by Chris Muller

I am pleased to announce a new release of Magma containing my updates since 1.1r1: - All underscore assignments have now been updated to ANSI assignments. - When opening the server, a file called "_open" is created in the repository directory, to indicate the repository is open. The file is deleted when the repository is closed gracefully. This is intended to help protect from accidentally letting two OS processes open the same repository files. - Resurrected MagmaDictionary! It is just like a Dictionary except that it inherits the properties of Magma's LargeCollections, such as size and concurrency. - Added Collection>>#asMagmaArray and MagmaArray>>#add:. - Added check for an additional way to run Squeak in headless mode: the "-vm-display-null" option. - Added MagmaSessionRequest class>>#signalNewReadStrategy: so that domains may signal new ReadStrategies to any listening sessions. - Added MagmaLocalLocation>>#findSession, a convenient counterpart to #newSession that first checks there is already a session open on that location and, if so, use that one. Otherwise, create and answer a new one. - Support for persistent, simple BlockClosures (e.g., with only references to arguments, not "self", any instVars or globals). - Choose automatically between an appropriate MaDictionary subclass, depending on whether the new Weak-Finalization mechanism from Igor is supported. - Several other minor fixes. The following represent the 1.1r2 configuration, in load-dependent order: "Magma client" { 'Collections-BTree-lr.73.mcz'. 'Ma exception handling-cmm.36.mcz'. 'Ma base additions-cmm.174.mcz'. 'MaFixedWidthReport-cmm.7.mcz'. 'Ma Statistics-cmm.24.mcz'. 'Ma files additions-cmm.13.mcz'. 'Ma contextual search-cmm.34.mcz'. 'Ma special collections-cmm.114.mcz'. 'WriteBarrier-cmm.28.mcz'. 'Ma Squeak domain-cmm.34.mcz'. 'Ma proxy support-cmm.42.mcz'. 'Ma traverse object graphs-cmm.31.mcz'. 'Ma object serialization-cmm.234.mcz'. 'Ma client server-cmm.215.mcz'. 'Magma client-cmm.490.mcz' } "for Magma server add" , {'Magma server-cmm.406.mcz'. } "for Magma tester add" , { 'Ma Armored Code-cmm.148.mcz'. 'Ma special collections tester-cmm.14.mcz'. 'Ma object serialization tester-cmm.32.mcz'. 'Magma tester-cmm.367.mcz' } These package versions are available in the "MagmaTester" project of squeaksource.com. - Chris

July 29, 2010

[Pharo-project] Pharo 1.1 host menu os x

by Michael Roberts

I gave the latest release a spin and it seams quit doesn't work (again). old reference -> http://code.google.com/p/pharo/issues/detail?id=1068 can someone confirm? if so do we want a new issue or reopen the old one? Also the host menu is not consistent with the world menu. for example the tools menu is different. Script manager is in one but not the other. The help browser text references it which is why i noticed. I haven't looked at the implementation. is there a way they are supposed to be kept in sync? cheers, Mike

July 29, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by Alexandre Bergel

> Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? > Like with the window announcement, I like them better as verbs describing the event, f.ex. > someAnnouncer on: TestStarted do: [] > someAnnouncer on: TestEnded send: #x to: y Someone else vote for this? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 29, 2010

Re: [Pharo-project] [Survey] Assess the cycles in your software

by Laval Jannik

Hi all, Just a small reminder for people who wants to participate. Thank you for your collaboration. Cheers, Jannik On Jul 19, 2010, at 08:36 , Laval Jannik wrote: > Hi Pharoers, and Smalltalkers in general, > > Have you seen waited to assess the cycles in your software? Now you can :) > > We request some of you to perform an experiment using DSM to see your software package structure and to fix cycles between packages. Our tool shows dependencies between packages and highlight some bad dependencies generating structure cycles. It also helps to understand dependencies. > > Your goal is to fill a survey using our tool. > I prepared a mini-tutorial about DSM and eDSM. It can help you to understand the visualization tool. > > To ease the use of our tool, I loaded it in a PharoCore1.2. And there are two archives available: > - the first contains an image with our tool with a model of Pharo loaded in it, so you can play with our tool on pharo itself. It can be downloaded here: http://dl.dropbox.com/u/7739334/dsmWithPharo.zip. Pay attention, the image is slow. > - the second contains the same thing without the model of Pharo. Here, you have to load your code, then populate a moose model and use the tool. It can be downloaded here: http://dl.dropbox.com/u/7739334/dsmWithoutPharo.zip > The two archives contain the tutorial and the survey. If you are a pharo integrator, we suggest you to take the one with Pharo model loaded, else the other. > > To use our tool, load your tool in Pharo. Then do "MoosePanel open", and import your software in Moose by "import from Smalltalk image". When it is imported, select your project in the list on the left of MoosePanel, and select "all model packages" on the list on center. > > Then, you have two choices: > - you can scan all your project: right click on "all model packages" and do DSM. > - or select "all model packages" then select some packages in the next list and right click, do DSM. > > After that, you can perform the survey (with reading of the tutorial). We need your answers for the end of August. So, you have two months to do it. > > If you have any question, just let me know. > > Best regards, > Jannik. > > --- > Jannik Laval > PhD Student - Rmod Team - INRIA > Certified Project Management Associate (IPMA) > http://www.jannik-laval.eu > http://rmod.lille.inria.fr > --- >

July 29, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by laurent laffont

On Thu, Jul 29, 2010 at 7:42 PM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > On 29.07.2010 17:45, Alexandre Bergel wrote: > >> Wow ! Fast !. >>> >>> That means it should be easy now to do a lot of exciting stuff. Show >>> tests progression, errors/failures as soon as they occur, log several >>> things, drink cocktails, meet beautiful girls ....that's really cool. >>> >> I will be in winter time in 1 week time. We have to enjoy now >> >> Alexandre >> > Nice! > Maybe it's just me, or could we not add Announcement to the end of every > Announcement subclass name though? > Like with the window announcement, I like them better as verbs describing > the event, f.ex. > someAnnouncer on: TestStarted do: [] > someAnnouncer on: TestEnded send: #x to: y > +1. I propose TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded Shouldn't we put announce in TestResult>>runCase: instead of TestCase>>runCase ? This way we can pass the result to the Annoucement object. Actually, self announce: SUTestEndAnnouncement. is not in the ensure: block. So if the test fails there's no annoucement sent. Cheers, Laurent > > Cheers, > Henry > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010

[Pharo-project] [update 1.2] #12070

by Marcus Denker

12070 ----- Issue 2723: TestRunner UI does not provide fly by help for buttons Issue 2724: Window button fly by help should start with uppercase Issue 2725: Debugger context menu items do not start with uppercase letter Issue 2726: Fly by help of debugger buttons should start with uppercase -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 29, 2010

Re: [Pharo-project] there are still references to PluggableButtonMorphPlus

by Marcus Denker

On Jul 29, 2010, at 7:35 PM, Mariano Martinez Peck wrote: > I am in PharoCore 12066 and there are still references to PluggableButtonMorphPlus, which doesn't exist anymore: > > As much as I understand what Stef did with Gary is to start to merge all those many many button classes into one. They removed all the *Plus ones, for example. The standard Pluggable one can now do what the Plus did. > 1) MorphicToolBuilder >> buttonClass > ^ PluggableButtonMorphPlus > > is it ok to change it to > > buttonClass > ^ PluggableButtonMorph > > ? > yes, did that. > 2) UITheme >> newButtonIn: aThemedMorph for: aModel getState: stateSel action: actionSel arguments: args getEnabled: enabledSel getLabel: labelSel help: helpText > > > |b| > b := PluggableButtonMorphPlus > on: aModel > getState: stateSel > action: actionSel > label: labelSel. > > .... > > is it ok to change it to > > |b| > b := PluggableButtonMorph > on: aModel > getState: stateSel > action: actionSel > label: labelSel. > > ? > I did that. > > 3) MorphicToolBuilderTests >> expectedFailures > "Polymorph override of PluggableButtonMorphPlus>>update: makes color not being updated anymore in respond to sending #changed:. Was this an intentional change and this test is obsolete?" > ^ #(testGetButtonColor) > > > I don't know how this one should be. But it should be updated, at least the class name. > Yes, the classname should be fixed. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 29, 2010

Re: [Pharo-project] PluggableThemedOverflowPanelMorph(Object)>>doesNotUnderstand: #statusColor

by Marcus Denker

On Jul 29, 2010, at 7:38 PM, Mariano Martinez Peck wrote: > ok...as martin said, recompiling (change and save) PluggableButtonMorph>>#update: > did the trick...weird. Now we need to include this fix ASAP in the stream.. > I did: -> fix all refrences to PluggableButtonPlus (and all other Undeclared) -> recompile the image. Works. > cheers > > mariano > > On Thu, Jul 29, 2010 at 7:23 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > We need help to solve this problem....I cannot do anything as I need the TestRunner. > > WE have http://code.google.com/p/pharo/issues/detail?id=2717 > > and http://code.google.com/p/pharo/issues/detail?id=2700 > > I tried a Compiler recompileAll but still have the same problem. > > Cheers > > Mariano > > > On Mon, Jul 26, 2010 at 11:02 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Just try open a TestRunner. You will get a DNU and that won't let you even debug the error. > > Pharo core version: PharoCore-1.2-12061 > > I attach PharoDebug.log > PluggableThemedOverflowPanelMorph(Object)>>doesNotUnderstand: #statusColor > > Issue: http://code.google.com/p/pharo/issues/detail?id=2717 > > Cheers > > Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 29, 2010

[Pharo-project] [update 1.2] #12069

by Marcus Denker

12069 ----- Issue 1699: A File out of existing code aborts when canceled Issue 2722: Fix some Undeclared References in 12068 Issue 2700: Bug opening TestRunner in 12062 and 12061 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 29, 2010