- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About EndOfStream notification [was Streams - #nextLine]

by Schwab,Wilhelm K

Stef, A statement on pros/cons sounds like a good place to start. Re the VW/Dolphin behavior, the way to look at the errors is that they tell you what went wrong and where. If the errors truly are superfluous, then you probably should be using #nextAvailable:, which truncates and does not raise errors. You asked about a backwardly compatible solution. I think the pluggable exception idea is probably the best bet for that. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Tuesday, June 09, 2009 3:20 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About EndOfStream notification [was Streams - #nextLine] > Nicolas, > > Adding #nextAvailable: hurts nothing, but changing #next: (and #next > too) will break existing code. In VW, it is only #next that has the > silent failure trap, and while Cincom was willing to consider a > change, they ultimately declined to make it. I am convinced that > Dolphin gets it right, but I would be surprised to see us adopt its > behavior. I would be thrilled if we did so, but doubt it will happen. > Failing such breaking changes, I need to create a way to have my code > work, which is why I started adding my own methods. > > Your pluggable exception/defaultAction idea is worth a shot. Some > simple testing should show whether it can preserve current behavior > and throw exceptions, respectively. I think I heard Stef as much as > say he would support it if it does serve both masters. Stef? As I said I would like to have a one page description of the problem, solution, pros and cons May be put it on the wiki Right now we are messy in terms of process for changes. I personnally always hated the VW behavior because we lost a lot of time with code trapping error. But I do not want to take decision on my emotion because I could be wrong. So do a one page proposal with problem, solution, pros and cons. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 9, 2009

Re: [Pharo-project] [Seaside] Seaside 2.8.4 image crashes [newbie]

by Lukas Renggli

This is certainly not your fault. It has probably to do with a missing plugin. I'll forward it to the Pharo list, maybe somebody knows more about this? I think I heard that problem before. Lukas On Tue, Jun 9, 2009 at 11:41 PM, Ivar Refsdal<refsdal.ivar(a)gmail.com> wrote: > Hello all, > > I'm a very fresh newbie, so the problem could just be myself. > Apologies in advance > if that is the case. However I'm getting a crash when doing the > following after starting Seaside with ./seaside.sh: > First going to http://localhost:8080/seaside/magritte/editor in a web browser, > then clicking 'Add' and then 'Save' without entering any data. > Then when clicking 'Preview' Seaside crashes with the following message: > > Segmentation fault > > 2022517340 UUID>initialize > 2022517224 Behavior>new: > 2022517132 >new > 2022517040 >uuid > 2022516948 >new > 2022516856 >defaultAccessor > 2022516764 MADescription>accessor > 2022516672 MADescription>hash > 2022516580 Dictionary>scanFor: > 2022516488 Set>findElementOrNil: > 2022516180 Dictionary>at:ifAbsent: > 2022516088 MAAdaptiveModel>readUsing: > 2022515996 MAMemento>pullRaw > 2022515840 OrderedCollection>do: > 2022515748 MAContainer>do: > 2022515656 MAMemento>pullRaw > 2022515564 MAMemento>pull > 2022515452 MACachedMemento>reset > 2022515360 MACheckedMemento>reset > 2022515268 >model:description: > 2022514976 MAContainer>asComponentOn: > 2022514884 Object>asComponent > 2022514792 MADescriptionEditor>preview > 2022514700 WASubmitButtonTag>on:of: > 2022514496 WAActionCallback>evaluateWithArgument: > 2022514036 WACallback>evaluateWithField: > 2022513760 WACallbackStream>processCallbacksWithOwner: > 2022509456 WAPresenter>processCallbackStream: > 2022509364 WAPresenter>processChildCallbacks: > 2022509272 WAComponent>decorationChainDo: > 2022509180 WAComponent>nextPresentersDo: > 2022509060 WAComponent>childrenDo: > 2022508968 SequenceableCollection>do: > 2022508836 WAComponent>childrenDo: > 2022508744 WAComponent>nextPresentersDo: > 2022508652 WAPresenter>processChildCallbacks: > 2022508560 WAPresenter>processCallbackStream: > 2022508392 WAToolFrame>processCallbackStream: > 2022508300 BlockClosure>on:do: > 2022508196 WAToolFrame>withDeprecatedHandlerDo: > 2022508104 WAToolFrame>processCallbackStream: > 2022508012 WARenderContinuation>processCallbacks: > 2022507884 WAComponent>decorationChainDo: > 2022504988 WARenderContinuation>processCallbacks: > 2022504896 WARenderContinuation>handleRequest: > 2022504804 BlockClosure>on:do: > 2022504712 WARenderContinuation>withNotificationHandler: > 2022504328 WARenderContinuation>handleRequest: > 2022501884 WASessionContinuation>value: > 2022501164 WASession>performRequest: > 2022501072 WASession>responseForRequest: > 2022500980 BlockClosure>on:do: > 2022500872 WASession>withErrorHandler: > 2022499892 BlockClosure>on:do: > 2022499800 WASession>withErrorHandler: > 2022499708 WASession>responseForRequest: > 2022499616 BlockClosure>on:do: > 2022499500 >use:during: > 2022499312 WASession>responseForRequest: > 2022499220 WASession>withEscapeContinuation: > 2022499128 >currentDo: > 2022499016 WASession>withEscapeContinuation: > 2022498904 WASession>responseForRequest: > 2022498812 WASession>incomingRequest: > 2022498548 BlockClosure>on:do: > 2022498456 WAProcessMonitor>critical:ifError: > 2022498364 BlockClosure>ensure: > 2022498272 WAProcessMonitor>critical:ifError: > 2022498640 BlockClosure>newProcess > Aborted > > I'm using this image file (no changes made): > http://www.seaside.st/distributions/Seaside-2.8.4.app.zip > Otherwise I'm on Ubuntu 9.04 i386, nothing special. Let me know if I > can provide more details. > I also tried executing the cleanup commands in the workspace, but it > didn't help. > The crash does not occur with the previous image I tried: Seaside-2.8-578.app. > > Any suggestions? > Thanks, > > Kind regards, > Ivar Refsdal > > (First post, hope everything went well.) > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Lukas Renggli http://www.lukas-renggli.ch

June 9, 2009

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by Frederic Pluquet

- the value of each instance variable is shown at left of the name of the inst var. - Descriptions are now limited to 5000 characters. The elements shown in "Elements" of an OrderedCollection are limited to the 500 first ones. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet On Tue, Jun 9, 2009 at 9:06 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > - Unfolding a branch that contains an element with a very > > very long > > printOn: seems to freeze the system. > > > > Ok, I should limit the size of the generated string (with ... at the > > end). > > > > I got an error niDescription not found. > > > > Do you have an example I can reproduce ? > > Hum... Load moose, CAnalyzer, then the linux kernel, and open a > NewInspector on the model. > I checked a bit the code, and apparently this issue will be solved if > you limit the size of the generated string. > > > - I spend a lot of time in unfolding branches to see field > > content. > > Maybe field values could be displayed without having to unfold ? > > > > Good idea. I'll see what I can do. > > Ok, I will be delighted to check it out > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 >

June 9, 2009

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by Frederic Pluquet

On Tue, Jun 9, 2009 at 7:57 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi frederic > > Here is some feedback > - Continue!!! Thanks :) > Now could you: > - add a class comment to classes. I have to browse the class > - categorise the methods. > - avoid using category in your package. > I do not want to have undocumented new code in pharo. Ok done. > > > - Instead of fields can you use > InstVar > Fields is not smalltalkish Done. > > > - when we use an inspector/explorer we can see really fast the value > of iv without > having to click on something. > may be you should propose something > classListIndex : 1 Difficult to do without speak to morphic directly. I must found another way. > > > - Why when I browse a symbol I do not get #in front? Fixed. > > - In some case we have contents what is it? Accessible elements of the collection. Changed to "Elements". For dictionaries, you have "Elements" (key => value, inspecting the value) and "Keys" (inspecting the keys objects, having a child "Value" to retrieve the associated value in the dictionary :)). > - why when I browse an array I do not get # ? > > > - roots are not obviously displayed > > It seems that you lost your symbol > > openOn: t1 > | t2 t3 t4 | > t3 := MorphicToolBuilder new. > (t4 := (t2 := self new on: t1; > yourself) buildWith: t3) > openInWorld. > ^ t2 > Yes, I have some problem with my image... I'll verify all my methods...

June 9, 2009

Re: [Pharo-project] ScriptLoader policies

by StÃ©phane Ducasse

It would be better to have a GlorpLoader package and GlorpLoader load (couple) it is more OO in the spirit. ScriptLoader is not for public consumption. stef On Jun 9, 2009, at 11:25 PM, Mariano Martinez Peck wrote: > Hi folks: I am making a new package in squeaksource for Glorp > (compatibility for Pharo) and I want Glorp to be easily loaded. > > I would love someone could dowload pharo and do ScriptLoader > loadGlorp :) > > Now, the question is, can I commit such method? Or ScriptLoader is > only for internal development? > > Thanks! > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 9, 2009

[Pharo-project] ScriptLoader policies

by Mariano Martinez Peck

Hi folks: I am making a new package in squeaksource for Glorp (compatibility for Pharo) and I want Glorp to be easily loaded. I would love someone could dowload pharo and do ScriptLoader loadGlorp :) Now, the question is, can I commit such method? Or ScriptLoader is only for internal development? Thanks! Mariano

June 9, 2009

Re: [Pharo-project] About EndOfStream notification [was Streams - #nextLine]

by StÃ©phane Ducasse

> Nicolas, > > Adding #nextAvailable: hurts nothing, but changing #next: (and #next > too) will break existing code. In VW, it is only #next that has the > silent failure trap, and while Cincom was willing to consider a > change, they ultimately declined to make it. I am convinced that > Dolphin gets it right, but I would be surprised to see us adopt its > behavior. I would be thrilled if we did so, but doubt it will > happen. Failing such breaking changes, I need to create a way to > have my code work, which is why I started adding my own methods. > > Your pluggable exception/defaultAction idea is worth a shot. Some > simple testing should show whether it can preserve current behavior > and throw exceptions, respectively. I think I heard Stef as much as > say he would support it if it does serve both masters. Stef? As I said I would like to have a one page description of the problem, solution, pros and cons May be put it on the wiki Right now we are messy in terms of process for changes. I personnally always hated the VW behavior because we lost a lot of time with code trapping error. But I do not want to take decision on my emotion because I could be wrong. So do a one page proposal with problem, solution, pros and cons. Stef

June 9, 2009

Re: [Pharo-project] About EndOfStream notification [was Streams - #nextLine]

by StÃ©phane Ducasse

On Jun 9, 2009, at 2:37 PM, Nicolas Cellier wrote: > 2009/6/9 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Nicolas, >> >> Adding #nextAvailable: hurts nothing, but changing #next: (and >> #next too) will break existing code. In VW, it is only #next that >> has the silent failure trap, and while Cincom was willing to >> consider a change, they ultimately declined to make it. I am >> convinced that Dolphin gets it right, but I would be surprised to >> see us adopt its behavior. I would be thrilled if we did so, but >> doubt it will happen. Failing such breaking changes, I need to >> create a way to have my code work, which is why I started adding my >> own methods. >> > > That's the price to pay, we have to break some #next: senders... > Inside the image, we can fix it easily. Bt how many should we fix? > I have 18 implementors (16 stream-like, 2 linked-list like) and 100 > senders in core, but when looking at them, few are prepared to get a > shorter collection than requested. > For example, I read: > (self next: 1) at: 1 > or: > header := strm next: 4. > self nSamples: header first nLevels: header second. > self setAlpha: header third beta: header fourth. > IMO, the change you request is a must in a majority of cases... so this looks like a good news :) > > It's of course better to see an immediate EndOfStreamError rather than > a delayed OutOfBoundError. > > For external packages, either the change is backported to other Squeak > branches on a collaborative basis (preferred), or we'll have to > maintain Pharo specific code on a competitive basis. > > Other squeak branches don't need to adopt our #next: behaviour, they > just have to provide a #nextAvailable: hook for compatibility, so I > don't think this is a real problem, especially if it enhances > portability. > > For #next, I can understand VW declined: > 1) they would have to change a bunch of senders > 2) they have to guarantee a certain degree of portability to their > clients, especially on such a heavily used kernel method. > In Squeak code too, there are just too many senders of #next, the > transition would be painfull without some backward compatibility. does a backward compatible with two path solution exist? > > >> Your pluggable exception/defaultAction idea is worth a shot. Some >> simple testing should show whether it can preserve current behavior >> and throw exceptions, respectively. I think I heard Stef as much >> as say he would support it if it does serve both masters. Stef? >> >> Bill >> >> > > Cost is small. > Think of adding a Nile compatible hook too. > >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of Nicolas Cellier >> Sent: Tuesday, June 09, 2009 2:34 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] About EndOfStream notification [was >> Streams - #nextLine] >> >> Bill, >> What I propose is to let programmer decide whether he will use >> Exception or not on endOfStream. >> And if he choose Exception, I underline that a defaultAction >> answering nil is not a panacea. >> But that defaultAction would still be an option if it solves your >> problem. >> >> Not sure my proposition does really solve the #next: problem you >> raised, indeed. >> The solution could be independant of endOfStream handling for this >> one. >> I support your request of creating a VW/Dolphin compatible >> #nextAvailable: and changing #next: to raise a >> NotEnoughElementAvailableError (maybe a subclass of >> EndOfStreamError). >> We would have a few package incompatibility, but, on ne fait pas >> d'omelette sans casser des oeufs... >> >> But I'm not convinced by the idea of duplicating the whole method >> protocol. >> Nor on duplicating the whole Stream class hierarchy, it's too big. >> That's were a classic delegation pattern can help (pluggable >> endOfStream). >> Of course, Trait composition is another option, and dynamic (on the >> fly) composition would be fun experimenting (as opposed to Static >> class definition). Keeping Traits as independant code units as >> possible is an interesting challenge (to explore the limits of such >> design). >> >> Nicolas >> >> 2009/6/9 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> >>> On Jun 8, 2009, at 9:32 PM, Nicolas Cellier wrote: >>> >>>> There are better examples where I want Exceptions, so I'd like the >>>> choice to be in programmers hands. >>>> - 1) Raising an EndOfStream Exception (and not a Notification as I >>>> suggested) should be optional >>>> - 2) The Exception should not have a default action. >>> >>> To add emphasis: it can't have a default action or it is not doing >>> its job. >>> >>> >>>> The simple thing to do is to add an endOfStreamAction >>>> instanceVariable to Stream or ReadStream. >>>> If a read past end is attempted, then ^endOfStreamAction value. >>>> >>>> nil value = nil, so letting this inst var uninitialized will lead >>>> to >>>> backward compatibility (at minimal cost concerning efficieny!). >>>> filling the inst var with a block comes to mind immediately, and >>>> among natural choice is: >>>> Stream>>willSignalEndOfStream >>>> self endOfStreamAction: [EndOfStream signal] >>>> >>>> There might be more work for Stream wrappers, but that sounds a >>>> cheap >>>> and efficient idea to reconcile both worlds. >>>> >>>> What will protect above code example from an internal low level >>>> EndOfStream? >>>> Nothing, but the fact that programmers using explicitely >>>> #willSignalEndOfStream will know what they do! >>>> Either they will protect with a handling block, or advertise enough >>>> that the code might generate spurious EndOfStream on malformed >>>> inputs... >>> >>> I hesitate to call the exceptions spurious; in situations where >>> they would be described as such, I generally would use >>> #nextAvailable: and write code that won't blow up. Exceptions do >>> a very important job: they carry information from the point of >>> detection of a problem to a place (often far removed on the stack) >>> where a corrective action can be reasonably applied. >>> >>> To (attempt) to paraphrase your idea, you are proposing to remove >>> the default action from EndOfStream, replacing that blunting of >>> exceptions with an uninitialized endOfStreamAction instance >>> variable that defalts to the same behavior, and can be set to >>> ensure raising of exceptions. Fair? >>> >>> This is certainly worth a try. For my part, the cost would be I >>> need to ensure that I set the exception behavior on every stream I >>> create vs. ensuring I use a different set of methods. It's >>> probably no worse, and maybe easier to enforce. I will generally >>> hide ReadStream on: behind a helper, #readStream, so I could just >>> as easily use #readStreamRobust to create the stream and activate >>> exceptions. Sorry to press this so hard, but I cannot afford to >>> have things breaking w/o telling me. At best, that wastes time to >>> track down mysterious failures, and worse, it can be dangerous. >>> It's not unlike the practice of building electronic enclosures >>> with lots of exposed grounded metal. It took me a while to gain >>> comfort with it, but the idea is that if a wire comes loose, it >>> hits ground, pulls a breaker, and goes into a safe mode and gets >>> attention as a side effect. >>> >>> Bill >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 9, 2009

Re: [Pharo-project] Syntax error loading Coral

by StÃ©phane Ducasse

good so the first things to do is to make sure that we can pass argument. CodeLoader or Image should have the primitive to get all the arg passed to the VM. Stef On Jun 9, 2009, at 8:41 PM, Luc Fabresse wrote: > The package loads now without any error. > > luc > > 2009/6/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > luc > > > > "UnixProcess>>argsAsFlatArrayAndOffsets:". I guess it is an UTF-8 > > > problem. > > > Any ideas for a solution ? > > could you repost an email with a clear test showing that it breaks? > like that the UnixProcess father may answer :) > Stef > > _______________________________________________ > 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

June 9, 2009

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by StÃ©phane Ducasse

On Jun 9, 2009, at 8:12 PM, Mariano Martinez Peck wrote: > > > - avoid using category in your package. > > > I know you answer Frederic but I am curious, why not using > categories in a package? Or I misunderstood that because we should get rid of them. And also having one category for one class just clutter the space It makes everything complex we have category that are not packages.... all kind of tools support for that. Stef > > > best, > > mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 9, 2009