November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Red Box of Doom when changing the Roassal Canvas of the Easle to Athens

by Alexandre Bergel

> ok i got the moose 5 image via pharolauncher and that solves the problem. However I see when I try bezierCurve example and try to move its elements around, morphic version is at least 4 times faster while the athens version is very slow. Why is that ? You are putting your finger on one big problem of Roassal. Roassal only loosely uses Athens. For example, the bezier line is composed of many small lines. With Morphic, I suspect that drawing 1000 times 1 line is as fast as drawing 1 times 1000 lines. In Athens, triggering a drawing takes times (since you need to define a path, and I guess the drawing is done by the graphic card). So, in Athens, drawing 1000 times 1 line, as it is done now with Bezier curve, is not really efficient. However, the good news is that I have a pretty good idea on how to fix this. Currently, Roassal does too much. It should not do the rendering loop. We soon plan to add a layer between Roassal and Athens to do the rendering loop. Thanks to this layer, all the good thing of Athens will be available in Roassal. In December I will lock myself in Igor office to extract all the juice of Athens. Alexandre > > > On Tue, Nov 26, 2013 at 10:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Have you tried to use the mouse distribution? > https://ci.inria.fr/moose/job/moose-5.0/lastSuccessfulBuild/artifact/moose-… > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Nov 26, 2013, at 5:16 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > > Nope I am afraid the problem remains. > > > > I went in Settings, did the select , unselect thing. Selected Monaco. Restored Roassal back to Morphic. Went to Easel , selected Canvas -> Athens and I get the MNU and Red Box of Doom once again. Tried Times New Roman and Courier , same problem. > > > > > > On Tue, Nov 26, 2013 at 10:02 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi Kilon, > > > > You need to change the font of Pharo. > > World Menu/systems/settings/Appearance > > Select "Use Free Fontâ. If it is selected, then unselect it and select it again. > > Change the source font of your image. Monaco is quite fine I find. > > > > Do your example again, you should not get the error anymore. > > > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > On Nov 26, 2013, at 3:47 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > > > > I get a MNU when I try to set Canvas in Easel (Roassal) to Athens. This is strange because I use also a very recent image and latest version from both Roassal and Athens at Win7 and I have no such problem. > > > > > > I am now on Macos 10.7 > > > > > > I had a similar problem when I tried to render text with Athens. Here is the stack. > > > > > > StrikeFont(Object)>>doesNotUnderstand: #glyphRendererOn: > > > AthensCairoCanvas>>setFont: > > > ROAthensCanvas>>drawString:at:font:color: > > > ROLabel>>drawOn:for: in Block: [ :line | ... > > > Array(SequenceableCollection)>>do: > > > ROLabel(ROAbstractLabel)>>linesOf:do: > > > ROLabel>>drawOn:for: > > > ROLabel(ROShape)>>chainedDrawOn:for: > > > ROBorder(ROShape)>>chainedDrawOn:for: > > > ROBox(ROShape)>>chainedDrawOn:for: > > > ROElement(ROAbstractComponent)>>drawOn: > > > ROViewStack(ROView)>>drawElementsOn: in Block: [ :n | n drawOn: canvas ] > > > OrderedCollection>>do: > > > ROViewStack(ROView)>>elementsToRenderDo: in Block: [ :assoc | assoc value do: aBlock ] > > > OrderedCollection>>do: > > > ROViewStack(ROView)>>elementsToRenderDo: > > > ROViewStack(ROView)>>drawElementsOn: > > > ROViewStack>>drawOn: > > > ROAthensMorph>>drawOn: in Block: [ :cs | ... > > > AthensCairoSurface>>drawDuring: in Block: [ ... > > > BlockClosure>>ensure: > > > AthensCairoSurface>>drawDuring: > > > ROAthensMorph>>drawOn: > > > FormCanvas(Canvas)>>draw: > > > FormCanvas(Canvas)>>drawMorph: > > > ROAthensMorph(Morph)>>fullDrawOn: in Block: [ ... > > > FormCanvas>>roundCornersOf:in:during: > > > FormCanvas(Canvas)>>roundCornersOf:during: > > > ROAthensMorph(Morph)>>fullDrawOn: in Block: [ ... > > > BlockClosure>>on:do: > > > > > > > > > > > >

Nov. 26, 2013

Re: [Pharo-dev] 2 month Pharo break

by Eliot Miranda

good luck! On Tue, Nov 26, 2013 at 3:24 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > Hi guys, > > I will cease my pharo activities for the next two months since I have to > finish my > thesis and I see myself too often "distracted" by pharo (consider this a > good thing :). > > Of course I will remain available for emergency activities or any other > urgent inquiries, > please contact me directly in these cases. > > see you on the other side! > -- best, Eliot

Nov. 26, 2013

Re: [Pharo-dev] The Second Coming of Java article

by StÃ©phane Ducasse

On Nov 26, 2013, at 9:53 PM, phil(a)highoctane.be wrote: > I also noticed that Sean does a replacement of the small size fonts with large size fonts in a specific way to speed up rendering of larger font (In his Configuration that does Preferences). I've got eyesight issues, so I am also using larger fonts. That doesn't help with speed indeed. > > But the Paragraph rendering code is also a culprit I think, as it endlessly recreates objects all the time. Igor was working on a new textEditor but he is down energy since a month. So we will see what will happen. Sadly he was working well with fernando. We will see if we can help him getting back to energy. Stef > > Morphs with step methods and a short stepping time are pretty fast. I've a educational game on the iPad that uses this and it is pretty nice in terms of rendering speed (dragging and dropping formula pieces around). > > > > --- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be | Web: http://philippeback.eu > Blog: http://philippeback.be | Twitter: @philippeback > Youtube: http://www.youtube.com/user/philippeback/videos > > High Octane SPRL > rue cour Boisacq 101 | 1301 Bierges | Belgium > > Pharo Consortium Member - http://consortium.pharo.org/ > Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com > Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller > > > > > On Tue, Nov 26, 2013 at 8:27 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2013/11/26 phil(a)highoctane.be <phil(a)highoctane.be>: > > Pharo really needs a huge speedup on the UI front. I am using a top of the > > line desktop system and still Pharo sometimes feels slow (some is due to > > algorithms - like the finder tool taking ages for a lot of things, but some > > is due to the UI system). > > > > This is not linked to the VM, as the MVC projects in Squeak are uber fast. > > > > Is the Text rewrite going to have an impact on this? > > It doesn't feel slow, it is slow. Perfectly usable, though. I even > feel it was faster before. > > But I think the problem comes from the "rendering" side, and not > because of "not UI" operations running in the main thread. > > > Regards, > >

Nov. 26, 2013

Re: [Pharo-dev] Red Box of Doom when changing the Roassal Canvas of the Easle to Athens

by kilon alios

ok i got the moose 5 image via pharolauncher and that solves the problem. However I see when I try bezierCurve example and try to move its elements around, morphic version is at least 4 times faster while the athens version is very slow. Why is that ? On Tue, Nov 26, 2013 at 10:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Have you tried to use the mouse distribution? > > https://ci.inria.fr/moose/job/moose-5.0/lastSuccessfulBuild/artifact/moose-… > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Nov 26, 2013, at 5:16 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > > Nope I am afraid the problem remains. > > > > I went in Settings, did the select , unselect thing. Selected Monaco. > Restored Roassal back to Morphic. Went to Easel , selected Canvas -> Athens > and I get the MNU and Red Box of Doom once again. Tried Times New Roman and > Courier , same problem. > > > > > > On Tue, Nov 26, 2013 at 10:02 PM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > > Hi Kilon, > > > > You need to change the font of Pharo. > > World Menu/systems/settings/Appearance > > Select "Use Free Fontâ. If it is selected, then unselect it and select > it again. > > Change the source font of your image. Monaco is quite fine I find. > > > > Do your example again, you should not get the error anymore. > > > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > On Nov 26, 2013, at 3:47 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > > > > I get a MNU when I try to set Canvas in Easel (Roassal) to Athens. > This is strange because I use also a very recent image and latest version > from both Roassal and Athens at Win7 and I have no such problem. > > > > > > I am now on Macos 10.7 > > > > > > I had a similar problem when I tried to render text with Athens. Here > is the stack. > > > > > > StrikeFont(Object)>>doesNotUnderstand: #glyphRendererOn: > > > AthensCairoCanvas>>setFont: > > > ROAthensCanvas>>drawString:at:font:color: > > > ROLabel>>drawOn:for: in Block: [ :line | ... > > > Array(SequenceableCollection)>>do: > > > ROLabel(ROAbstractLabel)>>linesOf:do: > > > ROLabel>>drawOn:for: > > > ROLabel(ROShape)>>chainedDrawOn:for: > > > ROBorder(ROShape)>>chainedDrawOn:for: > > > ROBox(ROShape)>>chainedDrawOn:for: > > > ROElement(ROAbstractComponent)>>drawOn: > > > ROViewStack(ROView)>>drawElementsOn: in Block: [ :n | n drawOn: canvas > ] > > > OrderedCollection>>do: > > > ROViewStack(ROView)>>elementsToRenderDo: in Block: [ :assoc | assoc > value do: aBlock ] > > > OrderedCollection>>do: > > > ROViewStack(ROView)>>elementsToRenderDo: > > > ROViewStack(ROView)>>drawElementsOn: > > > ROViewStack>>drawOn: > > > ROAthensMorph>>drawOn: in Block: [ :cs | ... > > > AthensCairoSurface>>drawDuring: in Block: [ ... > > > BlockClosure>>ensure: > > > AthensCairoSurface>>drawDuring: > > > ROAthensMorph>>drawOn: > > > FormCanvas(Canvas)>>draw: > > > FormCanvas(Canvas)>>drawMorph: > > > ROAthensMorph(Morph)>>fullDrawOn: in Block: [ ... > > > FormCanvas>>roundCornersOf:in:during: > > > FormCanvas(Canvas)>>roundCornersOf:during: > > > ROAthensMorph(Morph)>>fullDrawOn: in Block: [ ... > > > BlockClosure>>on:do: > > > > > > > > > > > >

Nov. 26, 2013

Re: [Pharo-dev] The Second Coming of Java article

by phil＠highoctane.be

I also noticed that Sean does a replacement of the small size fonts with large size fonts in a specific way to speed up rendering of larger font (In his Configuration that does Preferences). I've got eyesight issues, so I am also using larger fonts. That doesn't help with speed indeed. But the Paragraph rendering code is also a culprit I think, as it endlessly recreates objects all the time. Morphs with step methods and a short stepping time are pretty fast. I've a educational game on the iPad that uses this and it is pretty nice in terms of rendering speed (dragging and dropping formula pieces around). --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Tue, Nov 26, 2013 at 8:27 PM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > 2013/11/26 phil(a)highoctane.be <phil(a)highoctane.be>: > > Pharo really needs a huge speedup on the UI front. I am using a top of > the > > line desktop system and still Pharo sometimes feels slow (some is due to > > algorithms - like the finder tool taking ages for a lot of things, but > some > > is due to the UI system). > > > > This is not linked to the VM, as the MVC projects in Squeak are uber > fast. > > > > Is the Text rewrite going to have an impact on this? > > It doesn't feel slow, it is slow. Perfectly usable, though. I even > feel it was faster before. > > But I think the problem comes from the "rendering" side, and not > because of "not UI" operations running in the main thread. > > > Regards, > >

Nov. 26, 2013

Re: [Pharo-dev] The Second Coming of Java article

by phil＠highoctane.be

FWIW, I'd love to have a working Pharo bytecode interpreter that works. VMMaker currently doesn't have one it seems (earlier experiments didn't worked for me). I am very interested with the VM, read the blue book, understand the primitives, can somewhat read bytecode but what is needed now is the ability to run/debug a VM inside Pharo itself. GDB'ing is okay but a pain in the ass to understand what's going on. Also read the Tour of the OE of Tim Rowledge and Porting the VM etc. Also looked at the VMMaker package (Interpreter and Object Memory) + Slang. Now, getting an working interpreter would help me reach the next step. I am not talking about the Stack interpreter, but the plain Interpreter. Any plans? Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Tue, Nov 26, 2013 at 9:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Nov 26, 2013, at 1:21 PM, phil(a)highoctane.be wrote: > > I downloaded ST/X this morning and looked around for a couple hours. > > Impressive system. And impressive clients list/activities etc. > <rant> > And wow, Claus is yet another individual with top notch computer chops... > Seems that this community has the highest density of high perf brains. I > feel humbled indeed. > </rant> > > What struck me was the speed. > > > 15 years of working improving the VM pays off. > This is why the work of Eliot on Spur are also important. What is also > important is that more people can work on the VM > for cleaning it so that we get a documented and good vehicule. > And this will take time. We are working on a prototype to get forced to > think about VM and learn. But this prototype will > not replace Cog in the near future. So we should be happy that cog is > there and improving. > > Stef > > Pharo really needs a huge speedup on the UI front. I am using a top of the > line desktop system and still Pharo sometimes feels slow (some is due to > algorithms - like the finder tool taking ages for a lot of things, but some > is due to the UI system). > > This is not linked to the VM, as the MVC projects in Squeak are uber fast. > > Is the Text rewrite going to have an impact on this? > > On the front of interoperability, I personally have chosen to go the > RabbitMQ route, it allows me to wire all kinds of things together with some > room for scale. > > On the Java front itself, in the TCL community, we do have tclbend and > also a package to do the same thing as STX:LIBJAVA. Truth be told, there > hasn't been much traction in there. It works fine but that's it. > http://www2.tcl.tk/1313 - usage sample http://www2.tcl.tk/14919 > It also has fell behind in terms of keeping up with the latest versions of > the environment. > > In PHP, there is the Quercus and Caucho Resin Server that allows to run > PHP on top of the JVM and invoke Java from there. Some people run very fast > stuff on that, and benefiting from all JEE abilities (JMS, JTA, Clustering, > JAAS...) is really nice. http://www.caucho.com/resin-3.1/doc/quercus.xtp > > > Phil > > > > > On Tue, Nov 26, 2013 at 12:26 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> On 26/11/13 10:40, Serge Stinckwich wrote: >> >>> On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> >>> wrote: >>> >>>> On 26/11/13 03:28, askoh wrote: >>>> >>>>> >>>>> Bravo Jan and your collaborators. You have done it. >>>>> >>>> >>>> >>>> Thanks. >>>> >>>> >>>>> Anything preventing STX:LIBJAVA from being used in production >>>>> environments? >>>>> >>>> >>>> >>>> Good question. STX:LIBJAVA is still a research phase. However, if >>>> everything >>>> goes fine, we might have first project using it for real >>>> in couple months. >>>> >>>> >>> What is important is also the licence. Do you use an open-source licence >>> ? >>> >> >> Strictly speaking - no. For various, historical reasons. >> >> The Smalltalk part STX:LIBJAVA support code is available under >> the same terms as Smalltalk/X itself [1]. >> >> The code of the VM is not publicly available for various reasons, >> though it is possible to get an access. Ask Claus Gittinger if >> you're interested in details. >> >> >>> Anything preventing Pharo and VisualWorks for using the technology also? >>>>> >>>>> Short answer: Time and money. >>>> The way we did it requires significant changes to the virtual machine >>>> (as we believe this is the only way to get a decent performance). >>>> Indeed, if >>>> somebody going to pay for it, everything's possible ;-) >>>> >>> >>> You should try to ask ESUG about financial support. >>> >>> >> Maybe I should. But frankly - how many people in this community are like >> "That would be great, I need this feature!" Raise hands. :-) >> >> Cheers, Jan >> >> [1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup >> >> >> > >

Nov. 26, 2013

Re: [Pharo-dev] 2 month Pharo break

by StÃ©phane Ducasse

Thanks thanks thanks! I'm happy that you focus on the last run. Stef > Hi guys, > > I will cease my pharo activities for the next two months since I have to finish my > thesis and I see myself too often "distracted" by pharo (consider this a good thing :). > > Of course I will remain available for emergency activities or any other urgent inquiries, > please contact me directly in these cases. > > see you on the other side!

Nov. 26, 2013

Re: [Pharo-dev] about miniimage

by StÃ©phane Ducasse

> > Guillermo has several bootstrapped and minimal images. > I tried to find them but I could not > https://ci.inria.fr/pharo-contribution/job/Bootstrap/ > > Guillermo? Is now on holidays. > > Yes, but coding when not seeing family :) :) > https://ci.inria.fr/rmod/view/Oz/ OK I will try to have a look but I will teach three days in a row. > > Right now I kind of broke everythingâ¦ "Always have a running demo" :) > But what we have are mini images that just have an entry point method and quits. No repl cause they don't have even a compiler. "Ok may be just loading the compiler" would work ;) > > I will look around. > Stef >

Nov. 26, 2013

Re: [Pharo-dev] about miniimage

by StÃ©phane Ducasse

On Nov 26, 2013, at 3:27 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi Stef, > > I started to play with this way of shrinking (see the attachment). At least it's really faster than to use MC :-) Sure :) Do you have a ci job to produce an image systematically? > Where are the configurations you are creating? I started with a new configuration for RB I want Nautilus Zinc, Keymapping Gofer Fuel Morphic â¦ > > Cheers, > -- Pavel > > > 2013/11/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Nov 25, 2013, at 7:11 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > Hi Stef, > > > > our starting point looks like this: > > - we have a method how to produce small image without network etc. > > - we are able to load network, Monticello and Gofer in it (this job is currently broken) > > - we are able to load Metacello too - this should be the basic stage for normal users > > I would love to be able to grab an image up to the previous stage. Like that I can continue to work on the configurations regeneration project I have > > > - than we are a le to load rest od the system at once > > - we have several configurations that we are able to load and unload. > > > > Our biggest problem is the huge nonmodular step between Metacello image and full Pharo. I think we shoud move forward using division. To define how an image without development tools should look like and create two big configurations for them. Then continue with the next splitting. > > Yes > > > > > From the practical point of view, it's always faster to remove. something than to load something. > Fun since it was difficult for me to unload I thought that I should focus on load :) > > > > > And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy. > > > > -- Pavel > > > > 24. 11. 2013 v 22:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > >> Hi pavel > >> > >> may be I should start from your miniimage and start to making sure that the configurations can load then in a second step > >> I can make sure that they can unload. > >> > >> What do you think? > >> > >> Stef > > > > > > <shrink.st>

Nov. 26, 2013

Re: [Pharo-dev] The Second Coming of Java article

by StÃ©phane Ducasse

On Nov 26, 2013, at 1:21 PM, phil(a)highoctane.be wrote: > I downloaded ST/X this morning and looked around for a couple hours. > > Impressive system. And impressive clients list/activities etc. > <rant> > And wow, Claus is yet another individual with top notch computer chops... Seems that this community has the highest density of high perf brains. I feel humbled indeed. > </rant> > > What struck me was the speed. 15 years of working improving the VM pays off. This is why the work of Eliot on Spur are also important. What is also important is that more people can work on the VM for cleaning it so that we get a documented and good vehicule. And this will take time. We are working on a prototype to get forced to think about VM and learn. But this prototype will not replace Cog in the near future. So we should be happy that cog is there and improving. Stef > Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system). > > This is not linked to the VM, as the MVC projects in Squeak are uber fast. > > Is the Text rewrite going to have an impact on this? > > On the front of interoperability, I personally have chosen to go the RabbitMQ route, it allows me to wire all kinds of things together with some room for scale. > > On the Java front itself, in the TCL community, we do have tclbend and also a package to do the same thing as STX:LIBJAVA. Truth be told, there hasn't been much traction in there. It works fine but that's it. http://www2.tcl.tk/1313 - usage sample http://www2.tcl.tk/14919 > It also has fell behind in terms of keeping up with the latest versions of the environment. > > In PHP, there is the Quercus and Caucho Resin Server that allows to run PHP on top of the JVM and invoke Java from there. Some people run very fast stuff on that, and benefiting from all JEE abilities (JMS, JTA, Clustering, JAAS...) is really nice. http://www.caucho.com/resin-3.1/doc/quercus.xtp > > > Phil > > > > > On Tue, Nov 26, 2013 at 12:26 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 26/11/13 10:40, Serge Stinckwich wrote: > On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 26/11/13 03:28, askoh wrote: > > Bravo Jan and your collaborators. You have done it. > > > Thanks. > > > Anything preventing STX:LIBJAVA from being used in production > environments? > > > Good question. STX:LIBJAVA is still a research phase. However, if everything > goes fine, we might have first project using it for real > in couple months. > > > What is important is also the licence. Do you use an open-source licence ? > > Strictly speaking - no. For various, historical reasons. > > The Smalltalk part STX:LIBJAVA support code is available under > the same terms as Smalltalk/X itself [1]. > > The code of the VM is not publicly available for various reasons, > though it is possible to get an access. Ask Claus Gittinger if > you're interested in details. > > > Anything preventing Pharo and VisualWorks for using the technology also? > > Short answer: Time and money. > The way we did it requires significant changes to the virtual machine > (as we believe this is the only way to get a decent performance). Indeed, if > somebody going to pay for it, everything's possible ;-) > > You should try to ask ESUG about financial support. > > > Maybe I should. But frankly - how many people in this community are like "That would be great, I need this feature!" Raise hands. :-) > > Cheers, Jan > > [1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup > > >

Nov. 26, 2013