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

Re: [Pharo-project] Thoughts about Pharo GUI

by Igor Stasenko

just found http://code.google.com/p/libjit-linear-scan-register-allocator/wiki/LLVM_an… 2009/5/7 Igor Stasenko <siguctua(a)gmail.com>: > 2009/5/7 stepken <stepken(a)web.de>: >> Hi! >> >> Connecting Pharo to SUN Lively Morphic GUI: >> >> http://research.sun.com/projects/lively/ >> >> has lots of advantages: >> >> Â Â * decoupling of GUI and steering engine in hardware, like X-Server >> Â Â Â from X.org >> Â Â * independance of hardware and OS. >> Â Â * speed - drawing canvas in SVG is implemented in C, steeting in >> Â Â Â JAVA-Script. Google Chrome engine V8 is a ActionScript Jitter >> Â Â Â (http://llvm.org/) and even offers OpenGL as C-lib (Khronos) -> No >> Â Â Â more plugin's into VM necessary for graphics, same with >> Â Â Â vector-font libraries. >> Â Â * comfort - You can develop your smalltalk software from everywhere, >> Â Â Â e.g. pharo vm installed at a webhoster ... or local over loopback >> Â Â Â interface. >> Â Â * Lively and Squeak Morphic mental models fit perfectly, adaption >> Â Â Â should be really easy. Dan Ingall being one of the designers of >> Â Â Â Lively... >> Â Â * Pharo's killer applications seaside and pier also are remote >> Â Â Â applications, also using ActionScript and browser -> why not for >> Â Â Â graphics, morphic and etoys? >> Â Â * Chrome/FireFox tends to become the standard universal >> Â Â Â visualisation and I/O toolkit for all OS, so why not being >> Â Â Â lightyears ahead by consequently implementing the GUI in Chrome/FF? >> >> few disadvantages: >> >> Â Â * sound, videostreaming, printing problematic, but easily solvable, >> Â Â Â because FF/Chrome already have that features built in ;-) >> >> I'm a bit disappointed by the fact, that the squeak / pharo jitter still >> has not the expected performance impact. Elliot does a good work, but >> Frank Lesser with its DNG engine is showing actually, what is >> technically possible ...C-Speed for Smalltalk and ! Apple is behind LLVM >> and JAVA 6 is showing also, that C-Speed can be reached in full >> OO-Languages, see the "language shootout". By the way: ActionScript is a >> full OO-language, like Smalltalk. >> >> I really wondered, why not LLVM has become the standard jitter in Pharo. >> Power/ARM/Sparc/Intel ... processors are already supported! > > I studied LLVM functionality some time ago. And i don't remember what > exactly turns my nose off from it. Maybe because its too C-centric > approach: they care much about Globals, Linkage, custom-defined data > types, dynamic C code compilation which is totally have no use for > smalltalk. > I didn't found the ways how i could define own calling convention(s) , > other than cdecl. And to make smalltalk contexts efficient, IMO, you > have to change it. > From what i have seen, in examples like this > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html > Â .. LLVM is like a replacement of GCC compiler with mix of useful and > not so enhancements (in terms of smalltalk VM needs). Not sure how > this could help with making VM which could run smalltalk code - you're > still need to write it from scratch. > > Mainly, what i would like to reuse from LLVM is native code generator. > But again, from what i have seen, the code generator is focused to be > a backend for C compiler only. > That's only an impression, i could be wrong. > >> >> I think, any proprietary Jitter is a design fault ... >> >> just my 2 ct. >> >> Have fun, Guido Stepken >> >> _______________________________________________ >> 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.

May 7, 2009

Re: [Pharo-project] Thoughts about Pharo GUI

by Igor Stasenko

2009/5/7 stepken <stepken(a)web.de>: > Hi! > > Connecting Pharo to SUN Lively Morphic GUI: > > http://research.sun.com/projects/lively/ > > has lots of advantages: > > Â Â * decoupling of GUI and steering engine in hardware, like X-Server > Â Â Â from X.org > Â Â * independance of hardware and OS. > Â Â * speed - drawing canvas in SVG is implemented in C, steeting in > Â Â Â JAVA-Script. Google Chrome engine V8 is a ActionScript Jitter > Â Â Â (http://llvm.org/) and even offers OpenGL as C-lib (Khronos) -> No > Â Â Â more plugin's into VM necessary for graphics, same with > Â Â Â vector-font libraries. > Â Â * comfort - You can develop your smalltalk software from everywhere, > Â Â Â e.g. pharo vm installed at a webhoster ... or local over loopback > Â Â Â interface. > Â Â * Lively and Squeak Morphic mental models fit perfectly, adaption > Â Â Â should be really easy. Dan Ingall being one of the designers of > Â Â Â Lively... > Â Â * Pharo's killer applications seaside and pier also are remote > Â Â Â applications, also using ActionScript and browser -> why not for > Â Â Â graphics, morphic and etoys? > Â Â * Chrome/FireFox tends to become the standard universal > Â Â Â visualisation and I/O toolkit for all OS, so why not being > Â Â Â lightyears ahead by consequently implementing the GUI in Chrome/FF? > > few disadvantages: > > Â Â * sound, videostreaming, printing problematic, but easily solvable, > Â Â Â because FF/Chrome already have that features built in ;-) > > I'm a bit disappointed by the fact, that the squeak / pharo jitter still > has not the expected performance impact. Elliot does a good work, but > Frank Lesser with its DNG engine is showing actually, what is > technically possible ...C-Speed for Smalltalk and ! Apple is behind LLVM > and JAVA 6 is showing also, that C-Speed can be reached in full > OO-Languages, see the "language shootout". By the way: ActionScript is a > full OO-language, like Smalltalk. > > I really wondered, why not LLVM has become the standard jitter in Pharo. > Power/ARM/Sparc/Intel ... processors are already supported! I studied LLVM functionality some time ago. And i don't remember what exactly turns my nose off from it. Maybe because its too C-centric approach: they care much about Globals, Linkage, custom-defined data types, dynamic C code compilation which is totally have no use for smalltalk. I didn't found the ways how i could define own calling convention(s) , other than cdecl. And to make smalltalk contexts efficient, IMO, you have to change it. >From what i have seen, in examples like this http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html .. LLVM is like a replacement of GCC compiler with mix of useful and not so enhancements (in terms of smalltalk VM needs). Not sure how this could help with making VM which could run smalltalk code - you're still need to write it from scratch. Mainly, what i would like to reuse from LLVM is native code generator. But again, from what i have seen, the code generator is focused to be a backend for C compiler only. That's only an impression, i could be wrong. > > I think, any proprietary Jitter is a design fault ... > > just my 2 ct. > > Have fun, Guido Stepken > > _______________________________________________ > 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.

May 7, 2009

Re: [Pharo-project] Thoughts about Pharo GUI

by Sebastian Sastre

Hi Guido, since the oracle adquisition of sun in april 20, don't forget to add to the list something like: the only one that can say anything about its future is the Oracle board. Is obvious that oracle is only interested in java. Who can now say anything about valuable sun projects just vaporized by this adquisition? the industry will get stronger or weaker? for those products we can only wait and see. Right now there are plenty of scared sun consumers (not to mention mysql in pain pre-ex-users) sebastian > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > nombre de stepken > Enviado el: Wednesday, May 06, 2009 21:16 > Para: pharo-project(a)lists.gforge.inria.fr > Asunto: [Pharo-project] Thoughts about Pharo GUI > > Hi! > > Connecting Pharo to SUN Lively Morphic GUI: > > http://research.sun.com/projects/lively/ > > has lots of advantages: > > * decoupling of GUI and steering engine in hardware, like X-Server > from X.org > * independance of hardware and OS. > * speed - drawing canvas in SVG is implemented in C, steeting in > JAVA-Script. Google Chrome engine V8 is a ActionScript Jitter > (http://llvm.org/) and even offers OpenGL as C-lib > (Khronos) -> No > more plugin's into VM necessary for graphics, same with > vector-font libraries. > * comfort - You can develop your smalltalk software from > everywhere, > e.g. pharo vm installed at a webhoster ... or local > over loopback > interface. > * Lively and Squeak Morphic mental models fit perfectly, adaption > should be really easy. Dan Ingall being one of the designers of > Lively... > * Pharo's killer applications seaside and pier also are remote > applications, also using ActionScript and browser -> why not for > graphics, morphic and etoys? > * Chrome/FireFox tends to become the standard universal > visualisation and I/O toolkit for all OS, so why not being > lightyears ahead by consequently implementing the GUI > in Chrome/FF? > > few disadvantages: > > * sound, videostreaming, printing problematic, but easily > solvable, > because FF/Chrome already have that features built in ;-) > > I'm a bit disappointed by the fact, that the squeak / pharo > jitter still > has not the expected performance impact. Elliot does a good work, but > Frank Lesser with its DNG engine is showing actually, what is > technically possible ...C-Speed for Smalltalk and ! Apple is > behind LLVM > and JAVA 6 is showing also, that C-Speed can be reached in full > OO-Languages, see the "language shootout". By the way: > ActionScript is a > full OO-language, like Smalltalk. > > I really wondered, why not LLVM has become the standard > jitter in Pharo. > Power/ARM/Sparc/Intel ... processors are already supported! > > I think, any proprietary Jitter is a design fault ... > > just my 2 ct. > > Have fun, Guido Stepken > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 7, 2009

[Pharo-project] Thoughts about Pharo GUI

by stepken

Hi! Connecting Pharo to SUN Lively Morphic GUI: http://research.sun.com/projects/lively/ has lots of advantages: * decoupling of GUI and steering engine in hardware, like X-Server from X.org * independance of hardware and OS. * speed - drawing canvas in SVG is implemented in C, steeting in JAVA-Script. Google Chrome engine V8 is a ActionScript Jitter (http://llvm.org/) and even offers OpenGL as C-lib (Khronos) -> No more plugin's into VM necessary for graphics, same with vector-font libraries. * comfort - You can develop your smalltalk software from everywhere, e.g. pharo vm installed at a webhoster ... or local over loopback interface. * Lively and Squeak Morphic mental models fit perfectly, adaption should be really easy. Dan Ingall being one of the designers of Lively... * Pharo's killer applications seaside and pier also are remote applications, also using ActionScript and browser -> why not for graphics, morphic and etoys? * Chrome/FireFox tends to become the standard universal visualisation and I/O toolkit for all OS, so why not being lightyears ahead by consequently implementing the GUI in Chrome/FF? few disadvantages: * sound, videostreaming, printing problematic, but easily solvable, because FF/Chrome already have that features built in ;-) I'm a bit disappointed by the fact, that the squeak / pharo jitter still has not the expected performance impact. Elliot does a good work, but Frank Lesser with its DNG engine is showing actually, what is technically possible ...C-Speed for Smalltalk and ! Apple is behind LLVM and JAVA 6 is showing also, that C-Speed can be reached in full OO-Languages, see the "language shootout". By the way: ActionScript is a full OO-language, like Smalltalk. I really wondered, why not LLVM has become the standard jitter in Pharo. Power/ARM/Sparc/Intel ... processors are already supported! I think, any proprietary Jitter is a design fault ... just my 2 ct. Have fun, Guido Stepken

May 7, 2009

Re: [Pharo-project] UML diagram (OBEnhancement)

by David RÃ¶thlisberger

> I would not put superOb in scriptloader like that you can do what you > want and we too :) superOB per se is cool to have, the question is just which code OB uses for the UML generation. This code is defined in Mondrian, not in OB. So instead of removing superOB we better agree on a standard UML diagram format to be displayed. People can then switch themselves to an extended format, if they please. David > On May 6, 2009, at 4:18 PM, CÃ©drick BÃ©ler wrote: > >> Hi guys, (cc'ed to pharo list - we're talking about the UML diagram >> used in OBEnhancement) >> >> 2009/5/6 David RÃ¶thlisberger <roethlis(a)iam.unibe.ch>: >>> Hi CÃ©dric, >>> >>> I also like what you did for the UML diagram. >> I didn't push it to the repository because they were some personal >> choices and you underlined some of them. >> >>> Some issues I encountered: >>> >>> - class-side methods should not be at the bottom, but at the top, and >>> displayed with underlined font to be more UML-compliant. >> Oh I forgot about that. Looks ok to me though I don't know yet how to >> underline text in Mondrian (the text is a single stream with cr's) >> >>> - not sure about adding the method protocol. If included, I'd >>> rather go for >>> ordering the method alphabetically and then show the protocol in >>> parentheses >> yes there is an ordering problem. The alphabetical order is ok, but >> printing the protocol beside could lead to long lines and then wide >> rectangles in the diagrams. >> >> Even if not standard, I actually prefer the ordering by protocol >> mainly because it shows the method intention and it forces to use >> them. >> Nevertheless, to be consistent, I'd like to have a list of predefined >> protocols that can be ordered (initialize, accessing, ...) but this is >> outside the scope of the UML diagram. >> >> Could we agree on that in Pharo (standard list of method protocols) ? >> Can someone propose a starting point... >> >> What do you think ? (we could also provide an alternative ordering >> trough a popumenu "alphabetical/protocol") >> >>> - accessors should be present, IMO. >> I agree for the general case but decided to not show them in my >> diagrams. >> >> This is part of a wider strategy. I explore using ivar as slots and >> hence not consider accessors as methods. Each ivar has automatic >> accessors that I try to complete with pragma's for further processing. >> Something like <type: min: max: visibility: >... >> Just experiencing... but anyways, I find accessing methods adding too >> much extra noise in the diagrams. I'd prefer completing ivars with >> their visibility characteristic. Maybe another candidate for the >> popumenu (hide accessors). >> >> >>> - empty areas at the end should not be shown at all, eg. if there >>> are no >>> class methods, class vars. I'd instead suggest to show class vars >>> underlined >>> in the variable area at the top, class methods underlined at the >>> top of the >>> method area, which means that there are only two areas. If there >>> are no vars >>> or methods defined, keep the empty area, but having two or three >>> empty areas >>> is very confusing (and non-standard). >> ok, you're right. Still, I need to know how to underline text... Do I >> need to use TextAttribute ? Any pointers ? >> >>> For classes without methods and vars (there are some of those...) >>> we should >>> only show the rectangle with the class name. >> ok. >> >> >>> I'd very much appreciate if you could extend your implementation to >>> address >>> these issues. >> I'll try to do so ;) >> >> I've also planned to fill menus (browse, implement, senders, >> variables, etc... + export as PNG + ...) and hoverText (class comment, >> method definitions ...). >> >> Such a diagram could be an alternative/complementary way of browsing >> code... >> >>> Note that OB uses your implementation, as we rely on the class >>> UMLEnhClassDiagram from Alex' Mondrian version containing your >>> extensions. >> Yep, I saw that ;) >> >> Cheers, >> >> CÃ©drick >> >>> Thanks a lot, >>> David >>> >>>> I like your extension. Adding edges will not be a problem. You're >>>> the >>>> second one to ask for it. >>>> I will do some coding tonight or tomorrow, will come back to you >>>> soon. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On 30 Apr 2009, at 16:59, CÃ©drick BÃ©ler wrote: >>>> >>>>> Hi Alexandre and David, >>>>> >>>>> I just saw that you merged the development of Mondrian with >>>>> OBDiagram. >>>>> Sounds good to me. Though, I missed some information in the UML >>>>> class >>>>> diagram, so I did my own. I joined it in cas you'd like it (plus a >>>>> diagram example). One remark though, I simply remove accessing >>>>> methods >>>>> as I find they "pollute" my diagrams. It's ok for me but I guess >>>>> not >>>>> for general diagrams. >>>>> >>>>> I actually play more with accessing method so that I can have their >>>>> status and type (declaration in pragmas). Do you think it will be >>>>> doable to draw associations between classes (if declared in >>>>> pragmas) ? >>>>> >>>>> Cheers, >>>>> >>>>> -- >>>>> CÃ©drick >>>>> <UMLFullClassDiagram.st><xorp.png> >>> >> _______________________________________________ >> 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

May 6, 2009

Re: [Pharo-project] [OT] Pharo wallpaper

by Mariano Martinez Peck

On Wed, May 6, 2009 at 3:10 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > You can get the halos back using the preference > halosEnabled > Perfect!!! I could resize and put it as background :) Thanks! Mariano > > Stef > > On May 6, 2009, at 5:04 PM, Mariano Martinez Peck wrote: > > > > > > > On Thu, Apr 23, 2009 at 8:10 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com > > > wrote: > > When you put an image as background, is there an option to maximize > > it to the full zize instead of mosaic ? > > > > no one ? > > > > Since I don't have halos anymore, I don't know hot to resize > > (stretch) an image. > > > > Cheers, > > > > Mariano > > > > > > Thanks! > > > > Mariano > > > > > > On Thu, Apr 23, 2009 at 12:53 PM, Lukas Renggli <renggli(a)gmail.com> > > wrote: > > I am not a fan of photo wallpapers, but if there is a need for a > > picture I can offer this one: > > > > http://tinyurl.com/c3vqrx > > > > I made it on a trip with Stef to Nice in the village of Menton. > > > > Lukas > > > > On Thu, Apr 23, 2009 at 2:59 PM, Sebastian Sastre <ssastre(a)seaswork.com > > > wrote: > > > would be a good choice > > > sebastian > > > > > >> -----Mensaje original----- > > >> De: pharo-project-bounces(a)lists.gforge.inria.fr > > >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > > >> nombre de Torsten Bergmann > > >> Enviado el: Thursday, April 23, 2009 08:08 > > >> Para: pharo-project(a)lists.gforge.inria.fr > > >> Asunto: [Pharo-project] [OT] Pharo wallpaper > > >> > > >> The following wallpaper [1] looks very good behind the Watery > > Theme2 > > >> and the Pharo logo. It also gives an association with seaside. > > >> > > >> On the website it's claimed at least as free for download, it > > remains > > >> intellectual property of the media company. We could ask for > > >> permission > > >> or should digg in all our holiday photos to get something similar. > > >> > > >> [1] > > >> http://www.wallpapersphere.com/preview/scenery/seascape/1280+x > > >> +800/791/19581 > > >> [2] > > >> > http://www.wallpapersphere.com/nature-wallpapers/scenery/seascape.html > > >> > > >> -- > > >> Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + > > >> Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* > > >> http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > 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 >

May 6, 2009

Re: [Pharo-project] I always thought that 1 to: 100 do: was faster than (1 to: 100) do:

by StÃ©phane Ducasse

Great! This is a nice example to show all the tools we have for benchmarking. On May 6, 2009, at 8:46 PM, Nicolas Cellier wrote: > { > [(1 to: 100) do: [:i | i yourself]] bench. > [1 to: 100 do: [:i | i yourself]] bench. > }. > #('6935.01299740052 per second.' '44448.7102579484 per second.') > > You observe a Transcript dependent behavior, not related to to:do: > > 2009/5/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> but nicolas this is quite strange I unset the preference >> >> and I get >> 1 to: 1000 -> 3405 ms >> >> (1 to: 1000) -> 2600 ms >> >> I'm puzzled. Should probably increase the sample.... >> I redid the experience with exaclty the same setup and I get >> 26115 vs 25487 so this should be ok >> >> >> Stef >> >> >> >> On May 3, 2009, at 9:25 PM, Nicolas Cellier wrote: >> >>> I bet it's undo history again! >>> >>> reverse the order of the two tests and redo... >>> or deselect the preference for multipletextUndo. >>> >>> 2009/5/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> >>>>> >>>>> but apparently >>>>> http://code.google.com/p/pharo/issues/detail?id=750 >>>>> shows the contrary and this is really strange. I think that may be >>>>> this is a slow down in Transcript but... >>>>> >>>>> 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 >>> >> >> >> _______________________________________________ >> 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 >

May 6, 2009

Re: [Pharo-project] I always thought that 1 to: 100 do: was faster than (1 to: 100) do:

by Nicolas Cellier

{ [(1 to: 100) do: [:i | i yourself]] bench. [1 to: 100 do: [:i | i yourself]] bench. }. #('6935.01299740052 per second.' '44448.7102579484 per second.') You observe a Transcript dependent behavior, not related to to:do: 2009/5/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > but nicolas this is quite strange I unset the preference > > and I get > 1 to: 1000 -> 3405 ms > > (1 to: 1000) -> 2600 ms > > I'm puzzled. Should probably increase the sample.... > I redid the experience with exaclty the same setup and I get > 26115 vs 25487 so this should be ok > > > Stef > > > > On May 3, 2009, at 9:25 PM, Nicolas Cellier wrote: > >> I bet it's undo history again! >> >> reverse the order of the two tests and redo... >> or deselect the preference for multipletextUndo. >> >> 2009/5/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> >>>> but apparently >>>> http://code.google.com/p/pharo/issues/detail?id=750 >>>> shows the contrary and this is really strange. I think that may be >>>> this is a slow down in Transcript but... >>>> >>>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 6, 2009

[Pharo-project] Smalltalk -> MSE translator

by Alexandre Bergel

Dear All, Is there a Smalltalk -> MSE translator? Probably not since there is an importer. I am just wondering. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 6, 2009

Re: [Pharo-project] UML diagram (OBEnhancement)

by Alexandre Bergel

> ok, you're right. Still, I need to know how to underline text... Do I > need to use TextAttribute ? Any pointers ? Underlining is currently not supported. Let me work on this, it will be easier for me. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 6, 2009