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

Re: [Pharo-project] [squeak-dev] positionalMesssge breaks literal array parsing

by Igor Stasenko

On 24 March 2011 22:12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > Â Â Â the following won't parse because of support for positional messages > (whatever they are; I'll come to that later). http://www.lazarevic.de/PositionalArgs.html > Â Â Â Â Â #(word()) should be equal to { #word. #() } > but because of theÂ type == #leftParenthesis clause in the below it causes a > syntax error: > Scanner methods for multi-character scans > xLetter > "Form a word or keyword." > | type | > buffer reset. > [(type := self typeTableAt: hereChar) == #xLetter > or: [type == #xDigit > or: [type == #xUnderscore and:[self allowUnderscoreSelectors]]]] whileTrue: > ["open code step for speed" > buffer nextPut: hereChar. > hereChar := aheadChar. > aheadChar := source atEnd > ifTrue: [30 asCharacter "doit"] > ifFalse: [source next]]. > tokenType := (type == #colon or: [type == #xColon and: [aheadChar ~~ $=]]) > ifTrue: > [buffer nextPut: self step. > "Allow any number of embedded colons in literal symbols" > [(self typeTableAt: hereChar) == #xColon] whileTrue: > [buffer nextPut: self step]. > #keyword] > ifFalse: > [type == #leftParenthesis > ifTrue: > [buffer nextPut: self step; nextPut: $). > #positionalMessage] > ifFalse:[#word]]. > token := buffer contents > e.g. evaluate any of the following: > Â Â Â #(word()) > Â Â Â Compiler evaluate: '#(word())' > Â Â Â Scanner new scanTokens: '#(word())' > What is this support for? Â Is it for those funky ffi calls in the OpenGL > code? Â Can it not be hoisted out of the scanner and into the parser proper? > [and optimistically anyone have a fix already?] > best, > Eliot > > > -- Best regards, Igor Stasenko AKA sig.

March 24, 2011

Re: [Pharo-project] "Does Committing Code to an Open Source Project Mean Committing Career Suicide?"

by Igor Stasenko

On 24 March 2011 22:41, <csrabak(a)bol.com.br> wrote: > Hi Folks, > > In the interminable stream of conflicting information I've received this link: > > http://www.softwarequalityconnection.com/2011/02/does-committing-code-to-an… > > I will not say that the author's resume (shown in the page linked) increase my level of credibility on her posting, but given the popularity of the site from where it was posted, and IMNHO echoes a kind of FUD typically seen w.r.t. Open Source I thought you would like to get to know about. > > If any of the concerns described in the article should be considered correct, perhaps we should have the letters we sign for participating updated with the appropriate provisos? > Why? If you got hired by asshole, who thinks that he owns all of your free time, then my advice - just quit. Changing the letters, you sign, won't turn an asshole into a nice guy :) > Regards, > > -- > Cesar Rabak > > -- Best regards, Igor Stasenko AKA sig.

March 24, 2011

[Pharo-project] Issue 3876 in pharo: SqNumberParserTest>>testFloatGradualUnderflow has an odd condition

by pharo＠googlecode.com

Status: Accepted Owner: da...(a)teleport.com Labels: Importance-Low New issue 3876 by da...(a)teleport.com: SqNumberParserTest>>testFloatGradualUnderflow has an odd condition http://code.google.com/p/pharo/issues/detail?id=3876 SqNumberParserTest>>testFloatGradualUnderflow has an odd condition: In the following code, note that #areLowercaseDigitsAllowed is expected to return nil or notNil: "Parse the number in base 16 if possible - it is impossible if lowercase letter are allowed digits due to exponent letter ambiguity." float := self areLowercaseDigitsAllowed ifNil: [SqNumberParser parse: '16r2.D2593D58B4FC4e-256'] ifNotNil: [trueFraction asFloat]. but #areLowercaseDigitsAllowed returns true or false and in the 1.2 image it returns true ... implying that is impossible to parse? As it stands the `trueFraction asFloat` expression is always executed ... I'm trying to port SqNumberParser to GemStone and this little section of code is misleading, especially considering that GemStone doesn't pass the test:)

March 24, 2011

Re: [Pharo-project] Issue 3861 in pharo: Image freeze when changing system time

by pharo＠googlecode.com

Comment #3 on issue 3861 by siguc...(a)gmail.com: Image freeze when changing system time http://code.google.com/p/pharo/issues/detail?id=3861 this is known issue. but thanks for filing it on tracker. it should be fixed :)

March 24, 2011

[Pharo-project] "Does Committing Code to an Open Source Project Mean Committing Career Suicide?"

by csrabak＠bol.com.br

Hi Folks, In the interminable stream of conflicting information I've received this link: http://www.softwarequalityconnection.com/2011/02/does-committing-code-to-an… I will not say that the author's resume (shown in the page linked) increase my level of credibility on her posting, but given the popularity of the site from where it was posted, and IMNHO echoes a kind of FUD typically seen w.r.t. Open Source I thought you would like to get to know about. If any of the concerns described in the article should be considered correct, perhaps we should have the letters we sign for participating updated with the appropriate provisos? Regards, -- Cesar Rabak

March 24, 2011

Re: [Pharo-project] custom code on squeaksource

by Camillo Bruni

well the bitfield stuff would already work, thats fairly easy to implement. The only issue right now is that we rely on helvetia for the source code transformation. And I urge not to introduce custom syntax for slot creation, that doesn't make sense. Right now the class definition has always been hardcoded, which IMO is quite wrong. But by relying on first-class layouts in slots we can simply ask these objects what properties a class has. Just as a hint, first-class layouts render the format integer on classes basically useless. Since you can always query the layout and ask it for these properties. Thus the format should be used only at VM level to speed things up (the same for compact classes ;)). On 2011-03-24, at 22:04, StÃ©phane Ducasse wrote: >> yes now we should probably avoid to have syntax in the class definition but in a description of the slots. >> >> What means exactly: #identityHash => 20 => #Align => 32. >> >> This is just an example > > Yes I see that but I value real examples I cannot imagine :) > > So we could have a nice BitFieldSlot class with nice message and creation interface (no magic intepretation needed > and we would write something like > > HeapField subclass: #ObjectHeaderLittleEndian > instanceVar: > 'identityHash <BitFieldSlot length: 20 aligned: 32> ' > > or something like that and it will be quite cool. > > >> but it means a 20-bit unsigned integer field aligned on a 32-bit boundary. In the above #isPointers => 1 => #Boolean would mean a 1 bit-field accessed as a boolean (a flag). The above is close to the object header in the new GC I want to build. >> >> For slots we did a first experience with marcus in 2008/9 where we show that we could get first class instanceVariable >> without speed penalties. We postpone our experience because it required a working new compiler and a complete rewrite >> of classBuilder. >> We want to be able to define >> active value >> hashTable >> relationship >> magritte like description >> and a lot more >> >> So if you have ideas or wishes let us know. >> >> Stef

March 24, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by nullPointer

I donÂ´t understand something. The implementation of new widgets will based on SimpleMorphic, o really will be the base Morph is based in SimpleMorphic? If I could create new widgets and new UI functionalities I must work with SimpleMorphic? Will be change some things for work with openGL or others or really all is based in classic morphic? Regards. -- View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3403870.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 24, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by nullPointer

I donÂ´t understand something. The implementation of new widgets will based on SimpleMorphic, o really will be the base Morph is based in SimpleMorphic? If I could create new widgets and new UI functionalities I must work with SimpleMorphic? Will be change some things for work with openGL or others or really all is based in classic morphic? Regards. -- View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3403869.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 24, 2011

Re: [Pharo-project] [COTDC] 35 - MCPackageCache

by laurent laffont

Thanks Stef. Laurent. On Thu, Mar 24, 2011 at 9:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > I'm a kind of cache for versions and filenames of packages. > > Stef > > On Mar 24, 2011, at 7:18 PM, laurent laffont wrote: > > > Anyone or abort ? > > > > Laurent. > > > > On Wed, Mar 23, 2011 at 6:40 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > > Today: MCPackageCache > > > > > > Comment Of The Day Contest - One Day One Comment > > Rules: > > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > > #2: If you cannot comment it, deprecate it. > > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > > > Laurent > > > > >

March 24, 2011

Re: [Pharo-project] Issue 3861 in pharo: Image freeze when changing system time

by pharo＠googlecode.com

Comment #2 on issue 3861 by lem...(a)gmail.com: Image freeze when changing system time http://code.google.com/p/pharo/issues/detail?id=3861 Ok, i opened a ticket in the cog bugtracker. :-)

March 24, 2011