January 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [MC] [ANN] Sourcetalk

by Lukas Renggli

The complete documentation on Sourcetalk of Andrea Quadri is now online. This includes technical documentation and a users guide: http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi?query=Quadri Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 9, 2009

Re: [Pharo-project] Breakpoints (was [OT] Great job guys)

by Igor Stasenko

Even more smart-ass patching , to make OB happier :) Now if you open browser on BreakPointTestClass>>testMethod you will see an icon in method list changing when you installing/deinstalling the breakpoint by doing: BreakPointAgent class: BreakPointTestClass selector: #testMethod BreakPointAgent removeAll :) -- Best regards, Igor Stasenko AKA sig.

Jan. 9, 2009

Re: [Pharo-project] GUI editor, etc.

by GARY CHAMBERS

We have a package that provides Polymorph support for Magritte, as used in our ReportBuilder. I'm sure it would be no problem to get it released into SqueakSource :-) Regards, Gary ________________________________ From: Bill Schwab <BSchwab(a)anest.ufl.edu> To: pharo-project(a)lists.gforge.inria.fr Sent: Friday, 9 January, 2009 4:16:55 AM Subject: [Pharo-project] GUI editor, etc. Hello all, There was some recent mention of GUI frameworks and/or an editor. For fear of losing the idea, I will just throw this out now while I am thinking of it. I submit that one needs both a drag/drop graphical tool, and a programmatic capability. The graphical approach works well for many/most uses. Programmatic construction is very helpful for creating views to match RDB schemas, etc. Magritte might be of help in both scenarios, especially the programmatic side. We might get a lot out of simply "telling Magritte about Polymorph." So far at least, we seem to be using code, not data structures, to assemble views. That would make the graphical tool something that should work like I _think_ WindowBuilder does/did. My recollection is that it executed code to construct objects and then had the modified objects write code to recreate themselves. I fear we need to be careful about looking at the code to see how it works. Perhaps a little controversial, Tweak strikes me (please feel free to disagree/correct as appropriate) as using compiler/language changes to do things that can be (and so far, I would argue should be) accomplished by composition of objects with the language as-is. What Tweak shows as events in code browsers, I would prefer to see listed in a graphical tool editor. I'm pretty sure I recall WindowBuilder doing a nice job of that too. The toothpicks holding my eyes open are about to snap. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 9, 2009

Re: [Pharo-project] Breakpoints (was [OT] Great job guys)

by Igor Stasenko

Btw, with this trick its not necessary to break before invocation of method. You can put break just after method returns. Think , how powerfull it can be: (example) BreakPointAgent breakOnLeave: #isString class: Object condition: [:receiver :arguments: :result | Transcript show: receiver printString, '>>isString returns: ', result asString; cr. false "do not break" ]. 2009/1/9 Igor Stasenko <siguctua(a)gmail.com>: > 2009/1/9 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: >> Dale Henrichs wrote: >>> ----- "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> wrote: >>> >>> | And when you are already doing that, introduce also breakpoints back in >>> | Pharo as they are on GLASS GemTools. Very intuitive and the same as on >>> | most other Smalltalks. If they can be supported in GemTools, why >>> | aren't yet in Pharo? Any technical reason? >>> >>> Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm. >> >> What I like about breakpoints in GemTools is the simplicity from >> usability standpoint. And similarity of use to other Smalltaltalks. >> >> And because their UI part is implemented in OmniBrowser on GemTools, >> they should be easily ported back to Pharo OmniBrowser, even that >> breakpoints in GS/S are implemented differently than in Squeak. >> >> In other words, let we port the UI for breakpoints first, on top of >> whatever Squeak supports for breakpoints currently. Later breakpoints >> can be enhanced on VM level as well. >> > There is no need in any enhancement from VM side. > > Here attached the scratch implementation of breakpoints for squeak, > took about 15 minutes to implement. > > Usage: > > BreakPointAgent class:<yourclass> selector: <yourselector> "will > install a breakpoint on that method" > > BreakPointAgent removeAll "remove all breaks from system" > > BreakPointTestClass test " a simple test " :) > > now you can subclass it and create a conditional breakpoints, which > will halt only if some criteria met. > It is trivial to add new ivar (criteriaBlock) and change > run: aSelector with: arguments in: aReceiver > to halt only if criteriaBlock evaluates to true. > There is No limits to fantasy :) > > To not hide the actual method (when browsing) BreakPointAgent could be > extended to act as a proxy while it active e.g. simply redirect > messages like #literals and so on to compiled method it replaced. > >> Janko >> >> -- >> Janko MivÅ¡ek >> AIDA/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Jan. 9, 2009

Re: [Pharo-project] Breakpoints (was [OT] Great job guys)

by Igor Stasenko

2009/1/9 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > Dale Henrichs wrote: >> ----- "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> wrote: >> >> | And when you are already doing that, introduce also breakpoints back in >> | Pharo as they are on GLASS GemTools. Very intuitive and the same as on >> | most other Smalltalks. If they can be supported in GemTools, why >> | aren't yet in Pharo? Any technical reason? >> >> Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm. > > What I like about breakpoints in GemTools is the simplicity from > usability standpoint. And similarity of use to other Smalltaltalks. > > And because their UI part is implemented in OmniBrowser on GemTools, > they should be easily ported back to Pharo OmniBrowser, even that > breakpoints in GS/S are implemented differently than in Squeak. > > In other words, let we port the UI for breakpoints first, on top of > whatever Squeak supports for breakpoints currently. Later breakpoints > can be enhanced on VM level as well. > There is no need in any enhancement from VM side. Here attached the scratch implementation of breakpoints for squeak, took about 15 minutes to implement. Usage: BreakPointAgent class:<yourclass> selector: <yourselector> "will install a breakpoint on that method" BreakPointAgent removeAll "remove all breaks from system" BreakPointTestClass test " a simple test " :) now you can subclass it and create a conditional breakpoints, which will halt only if some criteria met. It is trivial to add new ivar (criteriaBlock) and change run: aSelector with: arguments in: aReceiver to halt only if criteriaBlock evaluates to true. There is No limits to fantasy :) To not hide the actual method (when browsing) BreakPointAgent could be extended to act as a proxy while it active e.g. simply redirect messages like #literals and so on to compiled method it replaced. > Janko > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig.

Jan. 9, 2009

Re: [Pharo-project] Breakpoints (was [OT] Great job guys)

by Janko MivÅ¡ek

Dale Henrichs wrote: > ----- "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> wrote: > > | And when you are already doing that, introduce also breakpoints back in > | Pharo as they are on GLASS GemTools. Very intuitive and the same as on > | most other Smalltalks. If they can be supported in GemTools, why > | aren't yet in Pharo? Any technical reason? > > Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm. What I like about breakpoints in GemTools is the simplicity from usability standpoint. And similarity of use to other Smalltaltalks. And because their UI part is implemented in OmniBrowser on GemTools, they should be easily ported back to Pharo OmniBrowser, even that breakpoints in GS/S are implemented differently than in Squeak. In other words, let we port the UI for breakpoints first, on top of whatever Squeak supports for breakpoints currently. Later breakpoints can be enhanced on VM level as well. Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Jan. 9, 2009

[Pharo-project] GUI editor, etc.

by Bill Schwab

Hello all, There was some recent mention of GUI frameworks and/or an editor. For fear of losing the idea, I will just throw this out now while I am thinking of it. I submit that one needs both a drag/drop graphical tool, and a programmatic capability. The graphical approach works well for many/most uses. Programmatic construction is very helpful for creating views to match RDB schemas, etc. Magritte might be of help in both scenarios, especially the programmatic side. We might get a lot out of simply "telling Magritte about Polymorph." So far at least, we seem to be using code, not data structures, to assemble views. That would make the graphical tool something that should work like I _think_ WindowBuilder does/did. My recollection is that it executed code to construct objects and then had the modified objects write code to recreate themselves. I fear we need to be careful about looking at the code to see how it works. Perhaps a little controversial, Tweak strikes me (please feel free to disagree/correct as appropriate) as using compiler/language changes to do things that can be (and so far, I would argue should be) accomplished by composition of objects with the language as-is. What Tweak shows as events in code browsers, I would prefer to see listed in a graphical tool editor. I'm pretty sure I recall WindowBuilder doing a nice job of that too. The toothpicks holding my eyes open are about to snap. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029

Jan. 9, 2009

Re: [Pharo-project] Splitting network package

by Bill Schwab

Michael, Excellent! I retract my re-iteration of the point :) Wasn't meaning to nag. You will find Ron capable (to say the least), helpful, etc. Thanks! Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> m.rueger(a)acm.org 01/08/09 2:01 PM >>> Bill Schwab wrote: > Michael, > > It might be nice to involve the cryptography maintainers; their work > could probably just add onto the structure you create. Great suggestion! Will do Michael _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 9, 2009

Re: [Pharo-project] Splitting network package

by Bill Schwab

No flame wars here. I do not yet know enough about the URL/I classes, but will gladly consider any good code. I will reiterate that it would be nice to get the cryptography guys involved (thinking of SSL in particular) if possible. Re complete replacement, as precedent, please note Nile. It is not in yet, but that is a stated goal, so I think you will find that such things will be given serious consideration. Now for something completely different - and what first grabbed my attention. You mentioned cherry picking changes. I cannot really offer any help just yet, except to note a couple of things that have been useful in Dolphin. The first is Ian Bartholomew's ChunkBrowser - it is a fantastic tool and should be ported/recreated in Pharo if at all possible. Obviously we would respect Ian's licensing terms, provide proper credit, etc. Did I mention that it is a NICE thing to have? :) I wrote and use a tool called Migrate for getting code out of one Dolphin image and into another. It has been sensitive to changes in the packaging system, but the general idea is to build a list of the currently installed packages and produce a script to load them into a new image. I added a concept of "safe" and "dangerous" loose methods. One might argue that only the dangerous methods (essentially overrides) are needed - I'm too tired to figure out why I have two types<g>, but I probably wrote it down somewhere. Migrate also arranges to file out and in those methods, but optionally on the in-side. I realize none of this is useful now, but I would expect to create Pharo versions of pieces that make sense in Pharo. Making sense will also be constrained in part by my level of use of Pharo over time. I have a LOT of Dolphin packages, so listing them in a sensible order is not a trivial task. I also hacked a few things that need to be reviewed when changing to a new version, and found ways to keep track of that w/o creating collisions with the base system packages. Feel free to run with any ideas that seem helpful. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> m.rueger(a)acm.org 01/08/09 1:51 PM >>> Hi all, updated MIME, URI and File packages in inbox. Some of the URI related changes are somewhat incomplete as I merged them from a different context. Hopefully I didn't break anything though :-) With merges like this it is really a problem that MC doesn't allow cherry picking changes... The overall goal with the URI changes is to complete replace the current Url implementation. We have done this quite successfully in Sophie and even more radically in the experimental ySqueak branch. Suggesting to replace Url classes by URI was a sure way to get a flame war going on the Squeak dev list. So what is general opinion on this for Pharo? Michael _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 9, 2009

Re: [Pharo-project] Platform class

by StÃ©phane Ducasse

I like that I really think that we need to have infrastructure support to control the complexity. I like the OBPlatform idea. After the question is how much layers do we need. I imagine that we should not have that much one this is well done. Does the Platform code you suggest conflicts with some existing ones that could be merged/migrated into. Stef On Jan 8, 2009, at 8:00 PM, Michael Rueger wrote: > Hi all, > > in Tweak there is a hierarchy of CPlatform classes (CPlatformWindows > etc) that provide a central place to add platform specific requests > and > avoid having the current platform detection code all over the system > > So instead of coding ExternalClipboard>>interfaceClass with all the > gory > details of platform detection you could just write > > Platform current externalClipboardClass > > We also used this in Sophie in connection with the FileLocations and > URI > package, supporting things like > > Platform current tempDirectoryURI > Platform current userDirectoryURI > etc > > > What do people think about introducing something similar (category > System-Platform) in Pharo? > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 8, 2009