- Pharo-dev - lists.pharo.org

Re: [Pharo-project] should the PharoDev hudson image be buld using the baseline instead?

by Dale Henrichs

Mariano, This isn't quite as bad as it sounds ... I suggest that you do load the baseline version of PharoDev, but in the project references of the baseline version use #stable or a specific version or #bleedingeEdge as a last resort. If a #stable version has been defined for a project, then you should be getting the 'latest stable version' as the project is updated. If no #stable version is defined, then you should use a literal version that is known to work. Use #bleedingEdge if that is the only way to get a project to load correctly ... Over time, you'd like to migrate all of the project references to #stable (in the baseline version) so that you will always be building hudson with the "latest version". When you release a one-click or hit another similar milestone where'd you'd like to record the state of the PharoDov system, then you can snap off the literal version of PharoDev where you record the literal version for each of the projects ... recording "in stone" the state of PharoDev... Dale On 01/18/2011 12:14 PM, Mariano Martinez Peck wrote: > Hi. A trade-off here. Right now, the PharoDev image from Hudson is > being built using ConfigurationOfPharo project lastestVersion. > This is more or less good because we have the last version of the > ConfigurationOfPharo. But at the same time, updating the versions of > ConfigurationOfPharo is tedious. So, what about loading the baseline > istead? So that metacello automatically load the latest version of each > package/project ? > The good thing is that every change in external configurations/packages > will be automatically included. But at the same time this is a > disavtange because we can build crap (someone commits something that > doesn't work). When updating ConfigurationOfPharo by hand we usually > test it before.... > > anyway, isn't this the idea if hudson? if it builds crap, we want to > know it, as soon as possible. NOBODY should use a Hudson image (as it > is now) for a stable Pharo1.2 image. > > what do you think? > > cheers > > mariano

Jan. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Sean P. DeNigris

Henrik Sperre Johansen wrote: > > AFAICT, #outOfWorld: might be the one you're looking for, it's called on > self and submorphs as part of #removeMorph: > So I THINK you'd get away with: > :) Good thought, and thanks for looking into it! However, that was my idea too; and it doesn't work. #outOfWorld: is also called when you embed a Morph in another Morph, for instance. So, even if the Morph is still open in the world, the subscriber list is hosed. Also, when #outOfWorld: is called, there is not enough context to tell whether it is being deleted or embedded, because the actual move happens after. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3223934.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 18, 2011

Re: [Pharo-project] splitters in table layout

by Andreas Wacknitz

Am 18.01.2011 um 20:58 schrieb Tudor Girba: > Yes, you missed a changeset Gary sent in the aligning morphs thread (he actually sent two, and you should pick the second one). > > Cheers, > Doru > Ah, thank you. I have found two messages with changesets from January 11th, 2011. After I filein the second changeset alas I will get a DNU Morph>>doFastWindowReframe: when I move the splitter... Regards, Andreas

Jan. 18, 2011

Re: [Pharo-project] Xtreams-Xtras: hashing and HMAC

by mkobetic＠gmail.com

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > > I didn't find a way to browse a "package" in Pharo 1.2 so I'm struggling a bit to keep the categories in line. > > Hmm, click the 'Browse' button in either the Monticello Browser or the Repository Browser with the correct package selected ? But I guess you know that as well... Well, those seem to be "read-only", i.e. any edits I try to make in those seem to disappear, so I've been ignoring those browsers. Interestingly, the one-click image (Pharo 1.1.1) seems to have 'browse package' in the SystemBrowser menus which seems to be more functional, but that doesn't seem present in the PharoCore 1.2, so I'm just getting by with the basic SystemBrowser atm. > The problem is the one I reported earlier: XTFileReadingWritingTest expecting a read stream to be aware of data written to a file after it was opened. This does not seem to work on Mac OS X. Yeah I have your previous report still in my inbox, but I'm kinda stuck there. As I said I don't have OSX to work with so I can't dig in to figure out what's going on. Given that it works on OSX in VW, I'm inclined to say that it should work on OSX in Squeak too. I wonder if there's some mixup in terms of file descriptors, maybe we're not talking to the same one or something such. I think Nicolas has OSX available so I'm hoping he might be able to find the time to look into it at some point.

Jan. 18, 2011

[Pharo-project] should the PharoDev hudson image be buld using the baseline instead?

by Mariano Martinez Peck

Hi. A trade-off here. Right now, the PharoDev image from Hudson is being built using ConfigurationOfPharo project lastestVersion. This is more or less good because we have the last version of the ConfigurationOfPharo. But at the same time, updating the versions of ConfigurationOfPharo is tedious. So, what about loading the baseline istead? So that metacello automatically load the latest version of each package/project ? The good thing is that every change in external configurations/packages will be automatically included. But at the same time this is a disavtange because we can build crap (someone commits something that doesn't work). When updating ConfigurationOfPharo by hand we usually test it before.... anyway, isn't this the idea if hudson? if it builds crap, we want to know it, as soon as possible. NOBODY should use a Hudson image (as it is now) for a stable Pharo1.2 image. what do you think? cheers mariano

Jan. 18, 2011

Re: [Pharo-project] splitters in table layout

by Tudor Girba

Yes, you missed a changeset Gary sent in the aligning morphs thread (he actually sent two, and you should pick the second one). Cheers, Doru On 18 Jan 2011, at 20:50, Andreas Wacknitz wrote: > Hi, > > Am 18.01.11 12:27, schrieb Gary Chambers: >> | m leftMorph scroll | >> m := PanelMorph new. >> m >> hResizing: #shrinkWrap; >> vResizing: #spaceFill; >> changeTableLayout; >> listDirection: #leftToRight. >> m addMorphBack: (leftMorph := Morph new >> color: Color red; >> minimumExtent: 150@10; >> extent: 150@10; >> hResizing: #rigid; "shown for clarity, is the default" >> vResizing: #spaceFill). >> m addMorphBack: (EdgeGripMorph new >> width: ProportionalSplitterMorph splitterWidth; >> hResizing: #rigid; "not the default this time, vResizing is also >> #spaceFill by default" >> target: leftMorph). >> m addMorphBack: (Morph new >> color: Color green; >> minWidth: 100; >> hResizing: #shrinkWrap; >> vResizing: #spaceFill). >> >> scroll := GeneralScrollPane new >> changeScrollerTableLayout; > In my Pharo-1.1 and 1.2 images > GeneralScrollPane>>changeScrollerTableLayout is not available. > Did I miss something? > > Regards, > Andreas > > -- www.tudorgirba.com "Every thing should have the right to be different."

Jan. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Tudor Girba

Who defended what status quo? The WeakAnnouncement are already on the agenda for 1.3. Cheers, Doru On 18 Jan 2011, at 20:40, Schwab,Wilhelm K wrote: > Of course. But when the status quo has been robustly defended, it seems reasonable to lobby for change as a start. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Tuesday, January 18, 2011 2:22 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Unsubscribing for Announcements > > Yes but having good weakstructure will not arrive by accident. > > > On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote: > >> Two comments: >> >> (1) there needs to be a way to unregister interest; >> (2) the registrations need to be weak so that (1) is largely optional. >> >> If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea. >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] >> Sent: Monday, January 17, 2011 1:18 AM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Unsubscribing for Announcements >> >> I really like Announcements! It's so much easier to update complex GUIs when >> you can pass state :) >> >> I hit one glitch when unsubscribing... The CollaborActive book suggests >> unsubscribing in #delete. For complex UIs, this doesn't seem to work >> because #delete is only called for the one morph that was deleted, not for >> its submorphs (which may need to unsubscribe). >> >> I tried this: >> MyMorph>>delete >> super delete. "Must come first. Deleting a submorph before self = >> emergency evaluator" >> aSubmorphThatNeedsToUnsubscribe delete. >> >> SubmorphMentionedAbove>>delete >> self inventory announcer unsubscribe: self. >> super delete. >> >> >> But it seems like a lot of work and coupling. Is there no hook that is >> guaranteed to be called when a morph is going away - i.e. it or a morph in >> the owner chain is being deleted? >> >> Thanks. >> Sean >> -- >> View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > -- www.tudorgirba.com "Every thing has its own flow."

Jan. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Tudor Girba

Who defended what status quo? The WeakAnnouncement are already on the agenda for 1.3. Cheers, Doru On 18 Jan 2011, at 20:40, Schwab,Wilhelm K wrote: > Of course. But when the status quo has been robustly defended, it seems reasonable to lobby for change as a start. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Tuesday, January 18, 2011 2:22 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Unsubscribing for Announcements > > Yes but having good weakstructure will not arrive by accident. > > > On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote: > >> Two comments: >> >> (1) there needs to be a way to unregister interest; >> (2) the registrations need to be weak so that (1) is largely optional. >> >> If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea. >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] >> Sent: Monday, January 17, 2011 1:18 AM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Unsubscribing for Announcements >> >> I really like Announcements! It's so much easier to update complex GUIs when >> you can pass state :) >> >> I hit one glitch when unsubscribing... The CollaborActive book suggests >> unsubscribing in #delete. For complex UIs, this doesn't seem to work >> because #delete is only called for the one morph that was deleted, not for >> its submorphs (which may need to unsubscribe). >> >> I tried this: >> MyMorph>>delete >> super delete. "Must come first. Deleting a submorph before self = >> emergency evaluator" >> aSubmorphThatNeedsToUnsubscribe delete. >> >> SubmorphMentionedAbove>>delete >> self inventory announcer unsubscribe: self. >> super delete. >> >> >> But it seems like a lot of work and coupling. Is there no hook that is >> guaranteed to be called when a morph is going away - i.e. it or a morph in >> the owner chain is being deleted? >> >> Thanks. >> Sean >> -- >> View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > -- www.tudorgirba.com "Every thing has its own flow."

Jan. 18, 2011

Re: [Pharo-project] splitters in table layout

by Andreas Wacknitz

Hi, Am 18.01.11 12:27, schrieb Gary Chambers: > | m leftMorph scroll | > m := PanelMorph new. > m > hResizing: #shrinkWrap; > vResizing: #spaceFill; > changeTableLayout; > listDirection: #leftToRight. > m addMorphBack: (leftMorph := Morph new > color: Color red; > minimumExtent: 150@10; > extent: 150@10; > hResizing: #rigid; "shown for clarity, is the default" > vResizing: #spaceFill). > m addMorphBack: (EdgeGripMorph new > width: ProportionalSplitterMorph splitterWidth; > hResizing: #rigid; "not the default this time, vResizing is also > #spaceFill by default" > target: leftMorph). > m addMorphBack: (Morph new > color: Color green; > minWidth: 100; > hResizing: #shrinkWrap; > vResizing: #spaceFill). > > scroll := GeneralScrollPane new > changeScrollerTableLayout; In my Pharo-1.1 and 1.2 images GeneralScrollPane>>changeScrollerTableLayout is not available. Did I miss something? Regards, Andreas

Jan. 18, 2011

Re: [Pharo-project] aligning morphs

by Tudor Girba

Hi Gary, Did you publish the changes to GeneralScrollPane somewhere? Cheers, Doru On 17 Jan 2011, at 12:07, Gary Chambers wrote: > It seems you are asking for the scroll value before the layout has been calculated. > (since the window hasn't received a fullbounds yet). > > > | m scroll | > m := PanelMorph new. > m > hResizing: #shrinkWrap; > vResizing: #spaceFill; > changeTableLayout; > listDirection: #leftToRight. > m addMorphBack: (Morph new > minWidth: 100; > hResizing: #shrinkWrap; > vResizing: #spaceFill). > scroll := GeneralScrollPane new > changeScrollerTableLayout; > scrollTarget: m. > scroll openInWindow. > scroll hScrollbar setValue: 1.0. > m addMorphBack: (Morph new > minWidth: 100; > hResizing: #shrinkWrap; > vResizing: #spaceFill). > "Recalculate bounds now for this example... not generally needed for normal code!" > scroll fullBounds. > "****" > scroll hScrollbar value > > Is not normally an issue, as you can see from inspecting the scroller after being opened. > > Regards, Gary > > ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, January 16, 2011 10:56 AM > Subject: Re: [Pharo-project] aligning morphs > > > Hi Gary, > > I would like to implement a Finder-like behavior the GeneralScrollPane. For this, I would need a way to control the scrolling so that every time I add a new morph, the scroller scrolls (similar to ScrollBar>>animateValue:duration: from OB). > > The problem seems to be that the scrollbar value is not updated when I add a new morph. Take a look at the code below. The result of the horizontal scrollbar value at the end is 1.0, while it should be lower. Am I doing something wrong, or is this a problem? > > | m scroll | > m := PanelMorph new. > m > hResizing: #shrinkWrap; > vResizing: #spaceFill; > changeTableLayout; > listDirection: #leftToRight; > m addMorphBack: (Morph new > minWidth: 100; > hResizing: #shrinkWrap; > vResizing: #spaceFill). > scroll := GeneralScrollPane new > changeScrollerTableLayout; > scrollTarget: m. > scroll openInWindow. > scroll hScrollbar setValue: 1.0. > m addMorphBack: (Morph new > minWidth: 100; > hResizing: #shrinkWrap; > vResizing: #spaceFill). > scroll hScrollbar value > > ==> 1.0 > > Cheers, > Doru > > > > On 11 Jan 2011, at 15:17, Gary Chambers wrote: > >> A slight revision as this has highlighted an edge case in the original class >> as to when scrollbars are needed... >> >> Regards, Gary >> >> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, January 11, 2011 1:53 PM >> Subject: Re: [Pharo-project] aligning morphs >> >> >> Excellent! >> >> I tried the example and it works well. I will work with it in the following days. >> >> Cheers, >> Doru >> >> >> On 11 Jan 2011, at 14:39, Gary Chambers wrote: >> >>> Try the attached change set with the following example... >>> Let me know if any use and we'll get it integrated. >>> >>> |m| >>> m := PanelMorph new. >>> m >>> fillStyle: Color green; >>> hResizing: #spaceFill; >>> vResizing: #spaceFill; >>> changeTableLayout; >>> layoutInset: 8. >>> m addMorph: (Morph new >>> height: 160; >>> minWidth: 100; >>> hResizing: #spaceFill; >>> vResizing: #shrinkWrap). >>> GeneralScrollPane new >>> changeScrollerTableLayout; >>> scrollTarget: m; >>> openInWindow >>> >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Monday, January 10, 2011 8:23 PM >>> Subject: Re: [Pharo-project] aligning morphs >>> >>> >>> Wow, that would be great! I cannot wait to test it. >>> >>> Cheers, >>> Doru >>> >>> >>> On 10 Jan 2011, at 16:50, Gary Chambers wrote: >>> >>>> I may get time later in the week to have a go with GeneralScrollPane to support the feature you desire... ;-) >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>> Cc: <Pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Monday, January 10, 2011 2:23 PM >>>> Subject: Re: [Pharo-project] aligning morphs >>>> >>>> >>>> Hi Gary, >>>> >>>> Thanks for the reply. >>>> >>>> So, what would be required for scrollbars to work with spaceFill? I would really need this feature, but I do not know how to go about it. >>>> >>>> Could you or anyone else provide some hints? Of course code would be even better. But at this moment hi ts would be helpful, too :) >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Jan 10, 2011, at 13:04, "Gary Chambers" <gazzaguru2(a)btinternet.com> wrote: >>>> >>>>> Hi Doru, >>>>> >>>>> #spaceFill constraints are typically only used by table layouts. >>>>> ScrollPane is designed for fixed size contents, at present. >>>>> Might be nice to extend it to honour any #spaceFill of its single target morph. >>>>> This would simplify usage of scrollers quite a bit! >>>>> >>>>> Regards, Gary >>>>> >>>>> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >>>>> To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> >>>>> Sent: Saturday, January 08, 2011 1:22 AM >>>>> Subject: [Pharo-project] aligning morphs >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I would need help with understanding the magic behind alignment in Morphic. >>>>> >>>>> Take the example from below. Could anyone help me with what I should do to have the morph stretch all the way horizontally? >>>>> >>>>> | scroll window morph | >>>>> scroll := ScrollPane new. >>>>> scroll >>>>> fillStyle: (SolidFillStyle color: Color blue); >>>>> vResizing: #spaceFill; >>>>> hResizing: #spaceFill. >>>>> morph := PanelMorph new. >>>>> morph >>>>> fillStyle: (SolidFillStyle color: Color yellow); >>>>> changeTableLayout; >>>>> listDirection: #topToBottom; >>>>> vResizing: #shrinkWrap; >>>>> hResizing: #spaceFill; >>>>> layoutInset: 10. >>>>> morph addMorphBack: (SimpleButtonMorph new width: 200; height: 200). >>>>> scroll scroller addMorph: morph. >>>>> window := SystemWindow new. >>>>> window addMorph: scroll fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)). >>>>> window openInWorld >>>>> >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing should have the right to be different." >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>> >>> >>> >>> <GeneralScrollPaneLayout.1.cs> >> >> -- >> www.tudorgirba.com >> >> "Some battles are better lost than fought." >> >> >> >> <GeneralScrollPaneLayout.2.cs> > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > > -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

Jan. 18, 2011