- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by StÃ©phane Ducasse

On Dec 5, 2013, at 7:48 AM, Max Leske <maxleske(a)gmail.com> wrote: > Thanks for the input. > > The problem with ReadStream and WriteStream is that they (at least in 2.0 and 3.0) never supported switching in the first place. #binary and #ascii simply answer self. That means the collection the stream operates on predetermines the output. Iâve noticed a couple of different approaches to solving this problem in the way that streams are used throughout the image and I want to make a list of those to see if thereâs some kind of pattern that maybe leads to an acceptable version with little changes as opposed to an optimal version where we have to change a lot of the implemenation details of streams. thanks such analysis is indeed important. > > Cheers, > Max > > > On 04.12.2013, at 19:45, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Here would be the Xtream way IMHO: >> 1) At the end, the file should be handled as binary. >> 2) A facade BivalentReadStream (and BivalentWriteStream) would be created, able to switch encoding >> 3) The implementation would be to wrap either directly over the binary stream, or indirectly over an encoded stream which wraps other the binary stream. >> 4) For write, the facade should just ensure that buffers (if any) are properly flushed, and then just delegate to specialized wrapped streams. >> 5) For read, it might be a bit more involved if some buffer were used in intermediate wrappers, because they should push back the excess bytes read and restore the state of lower level binary stream... >> In all case, all should happen thru delegation and the facade should be rather dumb. >> >> >> 2013/12/4 Sven Van Caekenberghe <sven(a)stfx.eu> >> >> On 04 Dec 2013, at 13:14, Max Leske <maxleske(a)gmail.com> wrote: >> >> > Let me see what I can come up with. >> >> To be somewhat compatible with existing streams, your memory stream should have the concept of âi am binary or textualâ and be able to switch in-place between these two states (#binary, #ascii). Depending on its state it should then return bytes or characters (or collections thereof). Have a look at ZnLimitedReadStream>>#next and/or ZnBivalentWriteStream>>#nextPut: >> >> To be 100% correct, encoding should be selectable. But maybe a default to utf-8 would be enough. You could have a look at ZnCharacter[Read|Write]Stream for inspiration. >> >> My 2c. >> >> > On 03.12.2013, at 19:36, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> > >> >> Thanks Max for the report. Do you have an idea on how we could solve the problem ? The previous behaviour was not acceptable either because the streams that came out of a memory filesystem were the only ones with binary content >> >> >> >> On Dec 3, 2013 5:35 PM, "Max Leske" <maxleske(a)gmail.com> wrote: >> >> Damien, Marcus >> >> >> >> this change breaks a lot of things in FileSystem-Git. I donât disagree with the idea that reading characters should be default (one could argue about itâ¦) but your change makes it IMPOSSIBLE to read bytes because unprintable characters are discarded! So if my ByteArray is a NULL terminated string, for instance, I can not check for the NULL termination anymore. >> >> >> >> Cheers, >> >> Max >> > >> >> >> >

Dec. 5, 2013

Re: [Pharo-dev] Committing slices to Pharo30Inbox still doesn't work for me

by Max Leske

Noted. Thanks Marcus. On 05.12.2013, at 08:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > It would be nice if someone else but me could do thisâ¦ small things like this can suck away *all* time > if only one person does them. > > (and no, I *never* had problems to submit a sliceâ¦) > > > On 04 Dec 2013, at 20:54, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> Hereâs a new slice, the corresponding packages are in the inbox. >> <SLICE-Issue-12324-There-should-be-no-class-side-implementations-of-packages-except-for-ClassDescription-StephanEggermont.2.mcz> > >

Dec. 5, 2013

Re: [Pharo-dev] Committing slices to Pharo30Inbox still doesn't work for me

by Marcus Denker

It would be nice if someone else but me could do thisâ¦ small things like this can suck away *all* time if only one person does them. (and no, I *never* had problems to submit a sliceâ¦) On 04 Dec 2013, at 20:54, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hereâs a new slice, the corresponding packages are in the inbox. > <SLICE-Issue-12324-There-should-be-no-class-side-implementations-of-packages-except-for-ClassDescription-StephanEggermont.2.mcz>

Dec. 5, 2013

Lectures at Prague

by StÃ©phane Ducasse

Alive and Kicking This presentation will discuss some successes stories around Smalltalk such AMD 64 bits, OOCL (http://www.oocl.com/) MediaGenix (www.mediagenix.tv) LAMRC (http://www.lamrc.com) netstyle.ch or yesplan.be. Then I will talk about Pharo and the recent advances in Pharo 20 and 30 alpha. More importantly I will give an overview of all the partners and shows that Pharo is composed of a really strong community of academic partners, research groups and companies. In addition I will stress that Pharo is YOUR open-source platform and that if you start to consider it as it then suddenly you realise that you want to improve it and that you can get an impact and influence Pharo's future and your future. I will finish by an key example showing the essence of object-oriented programming and prove to the audience that this is because of such example that Pharo is one of the best system to understand deeply object-oriented programming from its roots. Bio: Stephane leads the RMoD (http://rmod.lille.inria.fr) team. He is expert in two domains: object-oriented language design and reengineering. He worked on traits, composable groups of methods, and this work got some impact. Traits have been introduced in AmbiantTalk, and Squeak/Pharo, Perl, PHP and under a variant into Scala, Fortress of SUN Microsystems. He is one of the developer of Pharo http://www.pharo.org/ a new dynamic language used in industry and academia. He is also expert on software quality, program understanding, program visualizations, reengineering and metamodeling. He is one of the developer of Moose, an open-source software analysis platform http://www.moosetechnology.org/. He is working with http://www.synectique.eu/ a company building dedicated tools for advanced software analysis. He wrote several books: Pharo by Example and Deep into Pharo. He is president of ESUG http://www.esug.org Lecture: Prague Monday 9 December at The lecture starts at 4:15pm in the new Czech National Technical Library There will be a workshop wednesday / thursday afternoon Stef

Dec. 5, 2013

Smalltalker meeting at Prague

by StÃ©phane Ducasse

Hi guys I will be at Prague teaching from 9 to 13 december and we can organise a Smalltalker gathering for example after work. Tell me if you are interested. Stef

Dec. 5, 2013

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by Max Leske

Thanks for the input. The problem with ReadStream and WriteStream is that they (at least in 2.0 and 3.0) never supported switching in the first place. #binary and #ascii simply answer self. That means the collection the stream operates on predetermines the output. Iâve noticed a couple of different approaches to solving this problem in the way that streams are used throughout the image and I want to make a list of those to see if thereâs some kind of pattern that maybe leads to an acceptable version with little changes as opposed to an optimal version where we have to change a lot of the implemenation details of streams. Cheers, Max On 04.12.2013, at 19:45, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Here would be the Xtream way IMHO: > 1) At the end, the file should be handled as binary. > 2) A facade BivalentReadStream (and BivalentWriteStream) would be created, able to switch encoding > 3) The implementation would be to wrap either directly over the binary stream, or indirectly over an encoded stream which wraps other the binary stream. > 4) For write, the facade should just ensure that buffers (if any) are properly flushed, and then just delegate to specialized wrapped streams. > 5) For read, it might be a bit more involved if some buffer were used in intermediate wrappers, because they should push back the excess bytes read and restore the state of lower level binary stream... > In all case, all should happen thru delegation and the facade should be rather dumb. > > > 2013/12/4 Sven Van Caekenberghe <sven(a)stfx.eu> > > On 04 Dec 2013, at 13:14, Max Leske <maxleske(a)gmail.com> wrote: > > > Let me see what I can come up with. > > To be somewhat compatible with existing streams, your memory stream should have the concept of âi am binary or textualâ and be able to switch in-place between these two states (#binary, #ascii). Depending on its state it should then return bytes or characters (or collections thereof). Have a look at ZnLimitedReadStream>>#next and/or ZnBivalentWriteStream>>#nextPut: > > To be 100% correct, encoding should be selectable. But maybe a default to utf-8 would be enough. You could have a look at ZnCharacter[Read|Write]Stream for inspiration. > > My 2c. > > > On 03.12.2013, at 19:36, Damien Cassou <damien.cassou(a)gmail.com> wrote: > > > >> Thanks Max for the report. Do you have an idea on how we could solve the problem ? The previous behaviour was not acceptable either because the streams that came out of a memory filesystem were the only ones with binary content > >> > >> On Dec 3, 2013 5:35 PM, "Max Leske" <maxleske(a)gmail.com> wrote: > >> Damien, Marcus > >> > >> this change breaks a lot of things in FileSystem-Git. I donât disagree with the idea that reading characters should be default (one could argue about itâ¦) but your change makes it IMPOSSIBLE to read bytes because unprintable characters are discarded! So if my ByteArray is a NULL terminated string, for instance, I can not check for the NULL termination anymore. > >> > >> Cheers, > >> Max > > > > >

Dec. 5, 2013

Re: [Pharo-dev] Convert to Athens

by J.F. Rick

I've updated to the latest of Athens and I still get this bug, except now the square appears at 0@1. Cheers, Jeff On Wed, Dec 4, 2013 at 6:35 PM, J.F. Rick <self(a)je77.com> wrote: > Here's a piece of code to demonstrate the problem: > > AthensWrapMorph new > extent: 300@300; > addMorph: (Morph new > position: 100@100; > extent: 100@100; > yourself); > openInWorld. > > I think this should draw a blue square at 100@100. Instead, it draws a > blue square at 0@0. What am I doing wrong? > > Cheers, > > Jeff > > > > On Wed, Dec 4, 2013 at 6:17 PM, J.F. Rick <self(a)je77.com> wrote: > >> I'm facing some problems with AthensWrapMorph. Basically, when I add a >> morph, I can't change its position. It just stays in the top left. Whatever >> I try to do to change its position (self position: 100@100) does not >> work. >> >> Cheers, >> >> Jeff >> >> >> On Wed, Nov 20, 2013 at 5:04 PM, J.F. Rick <self(a)je77.com> wrote: >> >>> Thanks. It works. I already have found a few bugs and one thing I don't >>> understand. >>> >>> (1) A few Paint things seem to implement athensFillRectangle:on: and >>> athensFillPath:on: rather than fillRectangle:on: and fillPath:on:. It seems >>> like it should be the latter rather than the former. I changed the names >>> and the evil rectangle of doom disappeared. >>> >>> (2) Using the AthenWrapMorph, it seems that the bottom row of pixels is >>> not rendered or clipped. I can stop this phenomenon by changing the >>> createSurface method to have the extent be 0@1 bigger. While that >>> works, it seems like there's a bug somewhere in AthensCairoSurface. >>> >>> (3) I ended up changing a morph so that it should render differently. In >>> standard Pharo, I just use "self changed" and it updates. Is there an >>> equivalent in Athens? Do I have to explicitly tell Athens to rerender it? >>> If so, how? I tried "self render" but that did not seem to help. >>> >>> Cheers, >>> >>> Jeff >>> >>> >>> On Wed, Nov 20, 2013 at 11:08 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> http://www.smalltalkhub.com/#!/~Pharo/Athens >>>> >>>> >>>> On 20 November 2013 09:04, J.F. Rick <self(a)je77.com> wrote: >>>> >>>>> Right. Where is this Athens repository? I have the latest in >>>>> Pharo30/main (Athens-Morphic-MarcusDenker.23.mcz) and that does not seem to >>>>> include AthensWrapperMorph. >>>>> >>>>> Cheers, >>>>> >>>>> Jeff >>>>> >>>>> >>>>> On Wed, Nov 20, 2013 at 8:35 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 19 November 2013 17:42, J.F. Rick <self(a)je77.com> wrote: >>>>>> >>>>>>> Indeed. I would like to know that. It doesn't seem to be included in >>>>>>> the latest Pharo 3.0. >>>>>>> >>>>>>> >>>>>> it could be not yet included. >>>>>> in that case, load most recent Athens-Morphic package from athens >>>>>> repository. >>>>>> >>>>>> >>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Jeff >>>>>>> >>>>>>> >>>>>>> On Fri, Nov 15, 2013 at 7:34 PM, Hilaire Fernandes < >>>>>>> hilaire.fernandes(a)gmail.com> wrote: >>>>>>> >>>>>>>> Le 15/11/2013 14:17, Igor Stasenko a Ã©crit : >>>>>>>> > >>>>>>>> > for transition , i implemented a special morph, AthensWrapMorph >>>>>>>> > which wraps (as its name says) its children morphs and forces >>>>>>>> them to be >>>>>>>> > rendered by athens >>>>>>>> > (the child morphs will never receive #drawOn: but >>>>>>>> #drawOnAthensCanvas: >>>>>>>> > instead ). >>>>>>>> >>>>>>>> >>>>>>>> I guess Jeff, may want to know where to find this wrapper. >>>>>>>> >>>>>>>> Hilaire >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dr. Geo http://drgeo.eu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jochen "Jeff" Rick, Ph.D. >>>>>>> http://www.je77.com/ >>>>>>> Skype ID: jochenrick >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Jochen "Jeff" Rick, Ph.D. >>>>> http://www.je77.com/ >>>>> Skype ID: jochenrick >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> Jochen "Jeff" Rick, Ph.D. >>> http://www.je77.com/ >>> Skype ID: jochenrick >>> >> >> >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Dec. 5, 2013

Re: [Pharo-dev] [ANN] Roassal 3d

by Torsten Bergmann

> > 3. Providing a script is so "old style" and hard to remember - why not define a #stable > > and put your config into MetaRepoForPharo30 > > So others can easily load it via ConfigurationBrowser with a few clicks in a fresh image. > > Yes! Youâre very right. Can you add me as a contributor to MetaRepoForPharo30 ? I need this to commit right? I added you, but I think you can also commit without since this is in group Pharo, so I think anyone who contributes to Pharo is able to contribute to the meta repo for configs bye T.

Dec. 5, 2013

Re: [Pharo-dev] Opal hook?

by ClÃ©ment BÃ©ra

2013/12/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > I forgot to add that the OCUndeclaredVariableWarning was already handled > at semantic analysis. > This is not the case. The OCUndeclaredVariableWarning is handled in the default action. Therefore anyone can catch it. In this case for instance: [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example instanceVariableNames: ''customers accountID address name phoneNumber'' classVariableNames: '''' poolDictionaries: '''' category: ''Examples-Cookbook''' ] on: OCSemanticWarning do: [ :e | e halt ] The Semantic warning is caught outside of the semantic analysis and it works perfectly fine. The only thing is that you need to retry the error and not resume it to restart the semantic analysis (or you have an inconsistent execution state in the semantic analysis visitor). > Do you suggest that default behavior should be to handle and retry instead > of handle and return? > One way to achieve what you are asking would be to initialize the > Undeclared entry to some kind of ProtoObject that does not understand > anything and rethrow a OCUndeclaredVariableWarning instead of a > MessageNotUnderstood... (very uneasy to debug, since the Debugger itself is > querying the receiver etc... - unless Debugger is using basic mirror > primitives) > > > 2013/12/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > >> Steph, each time you want to evaluate something, do you agree that this >> involves >> - a parse phase of the expression you want to evaluate to create an AST >> - a code generation phase from AST -> bytecodes to generate a >> CompiledMethod >> - the evaluation phase itself which evaluates above CompiledMethod with >> appropriate receiver (nil generally) >> >> I didn't check OPAL, but do you agree that the semantic analysis >> determining which are those variables you called {'AnUnknownClass'. >> 'OCUndeclaredVariableWarning'. 'self'} and how to bind them, must happen >> somewhere between AST and CompiledMethod creation? >> >> So if there is a semantic exception, like UndeclaredVariable, how would >> the CompiledMethod be generated in the first place? >> If it's not generated, how would it be executed? >> If it's not executed, how would the message on:do: be sent to a block >> with 2 arguments? >> >> Unless you suggest to attempt executing a ParseTree which is known to be >> defectuous... >> >> 2013/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >>> AnUnknownClass subclass: #Adaptor1Example >>> instanceVariableNames: 'customers accountID address name >>> phoneNumber' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Examples-Cookbook' >>> >>> executes the default action for OCUndeclaredVariableWarning, which is >>> opening a pop-up titled: "Unknown variable ...". Here the error is raised >>> at *compilation time, *therefore it would have* no effect to wrap this >>> with a #on:do: * >>> >>> >>> I do not understand why if an exception is raised why I cannot trap it. >>> >>> [AnUnknownClass subclass: #Adaptor1Example >>> instanceVariableNames: 'customers accountID address name >>> phoneNumber' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Examples-Cookbook'] on: OCUndeclaredVariableWarning >>> do: [ self halt.] does not halt. >>> >>> The fact that is is at compilation time does not mean anything to me. So >>> why? I'm totally confused by this bad and unexpected behavior. >>> Do you imply that the warning is already trapped and that I cannot take >>> precedence? Probably but this has nothing to do with compilation time. >>> >>> Then to me OCSemanticWarning should be enhanced so that we do not get >>> these silly menus. An exception should work and clients should be able to >>> customise >>> it to (for example introduce menu and dialog with the users but they >>> should not be the only default. >>> We see again this plague of interactive environment not being rethought >>> in the 2013 age. >>> >>> defaultAction >>> self errorNotification ifFalse: [ ^nil ]. >>> ^self openMenuIn: >>> [:labels :lines :caption | >>> UIManager default chooseFrom: labels lines: lines title: caption] >>> >>> but that we could specify the action to be executed instead. >>> >>> >>> to me CompilerException should have nothing to do with UI and popup. >>> Then we should be able to pass objects that knows how to handle >>> the errors in interactive way or not. >>> >>> As a clear example, this is just bad that each time we want to change >>> the UI message we have to change the compiler exception. >>> ugly at wish. >>> >>> I have no cycle to fix that now. I will check if I can get something in >>> UndefinedObject so that I can continue to work on my task. >>> >>> Stef >>> >>> >>> >>> [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example >>> instanceVariableNames: ''customers accountID address name >>> phoneNumber'' >>> classVariableNames: '''' >>> poolDictionaries: '''' >>> category: ''Examples-Cookbook''' ] on: OCSemanticWarning do: [ >>> :e | e halt ] >>> >>> Here we catch the error, and you can handle it. >>> Now it is not easily possible to resume the error, because you want a >>> global instead and Opal expects a temp (there are way to resume but with >>> very deep stack manipulation that I do not want to show to young pharoers >>> present on this mailing list). So the best is to retry it. One solution is >>> therefore: >>> >>> [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example >>> instanceVariableNames: ''customers accountID address >>> phoneNumber'' >>> classVariableNames: '''' >>> poolDictionaries: '''' >>> category: ''Examples-Cookbook''' ] >>> on: OCSemanticWarning do: [ :e | >>> Smalltalk at: e node name put: StubRootClass. >>> e retry ] >>> >>> with e node name answering #AnUnknownClass here. >>> Now you need to make sure that the exception block is executed for the >>> case of a missing superclass and not something else or you will end up >>> creating loads of globals. >>> >>> The exception block should be something similar to: >>> >>> [ :e | >>> e node name first isUppercase and: [ "some condition" ] ifTrue: [ >>> Smalltalk at: e node name put: StubRootClass. >>> ^ e retry ]. >>> e pass ] >>> >>> *How to undefined and OCUndeclaredVariableWarning relate?* >>> >>> In your case, while loading from Monticello the code is compiled and >>> evaluated in non interactive mode. Therefore it cannot trigger the default >>> action of OCUndeclaredVariableWarning which is a UI event. So it sets by >>> default the unknown global to: >>> >>> Undeclared at: varName asSymbol put: nil. >>> OCUndeclaredVariable new name: varName asSymbol >>> >>> in: OCUndeclaredVariableWarning >>defaultAction >>> >>> which then later triggers the code in UndefinedObject. >>> >>> >>> >> >

Dec. 4, 2013

Re: [Pharo-dev] [ANN] Roassal 3d

by Alexandre Bergel

>> 3. Providing a script is so "old style" and hard to remember - why not define a #stable >> and put your config into MetaRepoForPharo30 >> So others can easily load it via ConfigurationBrowser with a few clicks in a fresh image. > > even better: have a jerkins build where people can download an imageâ¦ That would be great. How to do this? Cheers, Alexandre

Dec. 4, 2013