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

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Lawson English

Ironically, almost every newbie smalltalk programmer I know LIKES the IDE and thinks it is better than anything out there. BTW, if you want to see how smalltalk can be used as an embedded language, like at f-script... whose IDE, which everyone who uses it, loves, is very much a standard smalltalk IDE. L. On 1/14/12 9:22 PM, Gerry Weaver wrote: > Hello All, > > First, let me apologize for starting the Delphi thing. I only > mentioned it as an example IDE layout. I was not trying to say that > the internal workings of it were good, bad, or indifferent. > > I have spent some time playing around with things in Pharo. I have > been trying to imagine how I would use it on a typical project. I have > also been asking myself what it is about the current Smalltalk > implementations that are keeping them from being more popular. When I > consider the language/environment features that are commonly sited as > Smalltalk's strengths, I am surprised that there are so few real world > applications out there. I know folks are quick to point to a handful > of applications, but the numbers pale in comparison to the mainstream > languages. I don't share the same opinion on the productivity of the > IDE. It limits my productivity. > > DISCLAIMER: I am not trying to be critical of Pharo or Smalltalk in > general. I am trying to provide some feedback from a Smalltalk newbie > that has worked as a professional programmer for many years. I am not > trying to push or force my opinion on anyone. I'm just telling it the > way I see it. I apologize if anyone is offended by my words. This is > certainly not my intention. > > The following are some thoughts and observations about Smalltalk. > > 1. I believe Smalltalk's main strength is the language and it's library. > > 2. I don't think the image concept works in the current world. I > realize there are many folks who would argue this to death, but the > fact is that it hinders adoption. I believe it would be better to > focus on a robust full featured library and unload the maintenance of > the image based environment. I would think of Smalltalk as a Java > alternative. > > 3. I think Smalltalk should probably forget about the desktop gui > completely. There are so many good tools to build gui interfaces these > days that it would take a huge effort to match even half of the > functionality and performance they provide. Smalltalk should focus on > rich web interfaces instead. The gui code and tools are stealing > valuable resources from development. > > 4. Developing in Smalltalk should be just like any other high level > language. It should have a REPL type interface and it would also be > nice to have the capability to compile to a native executable. The > various Lisp implementations would be a good example. They too came > from a similar environment. > > 5. It should be possible to embed the Smalltalk VM in other languages > (ie; C/C++ etc.) with a nice two-way call interface (think Lua). This > would allow servers and GUIs written in other languages to leverage > Smalltalk for their application logic. > > 6. The IDE itself would probably be better written in another > language. This would ease platform integration, improve performance, > and make for a much richer experience overall. My personal choice for > this would be Nokia Qt. There is absolutely no reason that the same > browser, workspace, transcript based IDE environment wouldn't be > possible. This would also pave the way for IDEs like Eclipse, > Netbeans, etc. to provide plugins. > > 7. An interim solution to the items above would be to create a server > based interface to the Smalltalk image. This would allow an external > IDE to interact with the image in the same way that the embedded tools do. > > I like the Smalltalk language very much. I think it would make for an > awesome embedded scripting language. I also think that it is perfectly > suited to hosting the back-end business logic of a large application. > I think the best approach for the future is to focus on what Smalltalk > would be good at, and not waste valuable resources on things that it > is not really the right solution for. > > My personal plan for Smalltalk/Pharo is to create an external IDE and > a socket based interface in the Pharo image to support it. I also > intend to create an image manager server that can manage, monitor, and > communicate with multiple images. I have already been working on an > IDE for Lisp. Adding Smalltalk support seems logical. > > Okay.. I've dug my foxhole and I'm in it with my helmet on. Fire away! > > Thanks, > Gerry > > > > ------------------------------------------------------------------------ > -----Original Message----- > From: "GastÃ³n Dall' Oglio" <gaston.dalloglio(a)gmail.com> > To: Pharo-project(a)lists.gforge.inria.fr > Date: 01/14/12 10:06 > Subject: Re: [Pharo-project] New IDE alternative (was Misc. newbie > questions) > > Hello Blake. > > I like discuss about Delphi, but I don't say much more here > becouse this is a Smalltalk list :) > > 2012/1/13 blake < dsblakewatson(a)gmail.com > <mailto:dsblakewatson@gmail.com>> > > Gaston, > > > This method is for manage the event, not for do something > that is really part of the model. A Form, no is part of > the model. This is similar in VW: you coded your event > handler method in the AplicationModel, that is like a Form > in Delphi. > > > Delphi was a direct reaction to VB, which was eating Borland > Pasal's lunch. MVC was nowhere to be seen. It was all about > "look how easy it is to do [whatever]." Never "look how easy > it is to re-use" or "look how easy it is to maintain". I'm not > a Basic basher, but the atmosphere surrounding it has always > been "Computer science is =haaaaarrd=. I just wanna program!" > > > In general, the user of Delphi do not know how to make good > programming with it, becouse Delphi granted them make the things > quickly and bad. There are a VERY good book named "The dark side > of Delphi...", and the DARK word is for the general unknown about > it. Here is (in Spanish sorry): > http://www.marteens.com/pdfs/TheDarkSideOfDelphi6.pdf > > > You CAN do it right. But here I am (right now!) looking at a > guy who's encoded multi-hundred-line event handlers, that are > massive if-then chains, with code duplicated like crazy > between the events. > > > hehe, Maybe a sometime when I'm very hurry... but too in Delphi I > can use polimorphic, strategy, double dispatch, etc, for avoid use > of if-then. And no massive code, just necesary code for handle > event, just in VisualWorks :) > > Really, the "beauty" of the VB model is that you didn't HAVE > to learn OO. (And, hey, reality bears out that code quality > and profit are not strongly correlated.) > > No. The IDE automaticaly define a global variable and > create code for create and assign a instance, but if you > want more instances of same Form you can easy declare > local variables and create new instance (on initialize of > other instance or on the fly in accesor methods) and asign > to. Same in Smalltalk.... And you can delete this > automaticaly created code. > > > Sure. You can do a lot of things right. The underlying > weakness is in the static typing and poorly defined messaging. > (I haven't tried FireMonkey yet, though, it may be different.) > > > Sure! I completely agree with you. You are deal with reserved > words like "virtual, override, dinamic" for achieve dinamic > message dispatch across static variable typing. This is very > inconveniente for clean code (and has bad psychological > consequences in the developers hehe). > I do not try the Embarcadero version (and I do not), but them > improved some things. For example added use de "Class Helper" for > do some similar a trait to a class (but in a context). No only > Smalltalk evolves :). FYI see:: > http://edn.embarcadero.com/article/34324 > > > mmm no. Again, a Form is not part of model, idealy this is > for write event methods handlers. > > > I'm glad you're following the ideal. I started using Delphi on > the beta in 1994, and in the past 18 years, I've seen about > two instances of the ideal being properly followed in the real > world (that I didn't write). > > > hehe, again, "the DARK side..." never is very popular. > > In the Buttons you can use Actions for delegate the > handler method of the click event. In general, you can > assign method of a Form to events of controls in another > Form, but I do not do often that becouse I only write a > small code in the event handler in the Form for delegate > to some model the work (DataModules). > > > Point is: Buttons then become inflexible pass-throughs. In > Smalltalk what you'd do is allow a component to be swapped for > any other component if it had the right handlers. > > > In Delphi I can change the component too if they has the right > handlers with out major work, but I agree with you in that this in > not possibly do it easily that in Smalltalk. But, the class of the > variable that hold the current component should be ancestor of > both interchangeables components, very inconvenient! > > If you could lay out forms in Smalltalk and press a button to > create a lean, deployable version, I'd only use Delphi for CPU > intensive tasks. What'd be optimal is a Smalltalk (with some > VA/Delphi influences) in a browser with an overall approach > like that of OPA or maybe Morfik (not Morphic) so that front > and back-end stuff was seamless. Smalltalk was born for that. > > > :) > > Regards. > GastÃ³n. >

Jan. 15, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Stefan Marr

Hi: On 15 Jan 2012, at 09:53, Frank Shearar wrote: > On 15 January 2012 04:22, Gerry Weaver <gerryw(a)compvia.com> wrote: > > * a TCP-based interface in the Smalltalk image > >> Okay.. I've dug my foxhole and I'm in it with my helmet on. Fire away! I hope you guys are aware of Spoon: http://thiscontext.wordpress.com/2011/06/09/my-favorite-text-editor-editing… http://thiscontext.wordpress.com/category/spoon/ Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 15, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Frank Shearar

On 15 January 2012 04:22, Gerry Weaver <gerryw(a)compvia.com> wrote: > 2. I don't think the image concept works in the current world. I realize > there are many folks who would argue this to death, but the fact is that it > hinders adoption. I believe it would be better to focus on a robust full > featured library and unload the maintenance of the image based environment. > I would think of Smalltalk as a Java alternative. I have a minor nit here: it's not an image that's the problem, it's living in the image. Great for rapid development, and very easy to tangle things together. But the community's making increasing use of build tools and configuration management, especially in the form of Metacello. > 4. Developing in Smalltalk should be just like any other high level > language. It should have a REPL type interface and it would also be nice to > have the capability to compile to a native executable. The various Lisp > implementations would be a good example. They too came from a similar > environment. Lisps are image-based systems, but one tends to construct one's working image from a base image + extras. SBCL's SAVE-LISP-AND-DIE lets you turn that image into an executable. I don't think anyone would particularly care - or even know - that their TextLint is, on the inside, some small image + VM. In short, I don't think it's a lot of work to get something ostensibly a native executable, and I don't think that compiling to a native executable's particularly valuable. (Java applications aren't compiled to a native executable, for instance!) > 7. An interim solution to the items above would be to create a server based > interface to the Smalltalk image. This would allow an external IDE to > interact with the image in the same way that the embedded tools do. That also permits general Smalltalk-written remote tools like remote debuggers! > My personal plan for Smalltalk/Pharo is to create an external IDE and a > socket based interface in the Pharo image to support it. I also intend to > create an image manager server that can manage, monitor, and communicate > with multiple images. I have already been working on an IDE for Lisp. Adding > Smalltalk support seems logical. If I may suggest, take a look at Common Lisp's SLIME/swank architecture. (I'll be looking at this soon, with an eye towards connecting emacs to a running image.) With a standard protocol in place, one could connect _any_ IDE (plus plugin) to the image. I've spoken to a colleague about this kind of thing, and he suggests taking a look at https://github.com/ivan4th/swank-js because its architecture is rather simple, thus amenable to analysis and cribbing. _My_ personal plan is * a TCP-based interface in the Smalltalk image * a translating adapter between standard Squeak/Pharo syntax and GNU Smalltalk syntax (for "lexically scoped" class/method definitions) * an emacs mode for loading files or parts of files * ... and then copy a whole bunch of the above for the same thing for Newspeak. > Okay.. I've dug my foxhole and I'm in it with my helmet on. Fire away! > > Thanks, > Gerry > > > > ________________________________ > -----Original Message----- > From: "GastÃ³n Dall' Oglio" <gaston.dalloglio(a)gmail.com> > To: Pharo-project(a)lists.gforge.inria.fr > Date: 01/14/12 10:06 > Subject: Re: [Pharo-project] New IDE alternative (was Misc. newbie > questions) > > Hello Blake. > > > > I like discuss about Delphi, but I don't say much more here becouse this is > a Smalltalk list :) > > 2012/1/13 blake < dsblakewatson(a)gmail.com> >> >> Gaston, >> >> >> >>> >>> >>> >>> >>> This method is for manage the event, not for do something that is really >>> part of the model. A Form, no is part of the model. This is similar in VW: >>> you coded your event handler method in the AplicationModel, that is like a >>> Form in Delphi. >>> >> >> >> >> >> Delphi was a direct reaction to VB, which was eating Borland Pasal's >> lunch. MVC was nowhere to be seen. It was all about "look how easy it is to >> do [whatever]." Never "look how easy it is to re-use" or "look how easy it >> is to maintain". I'm not a Basic basher, but the atmosphere surrounding it >> has always been "Computer science is =haaaaarrd=. I just wanna program!" >> > > > > In general, the user of Delphi do not know how to make good programming with > it, becouse Delphi granted them make the things quickly and bad. There are a > VERY good book named "The dark side of Delphi...", and the DARK word is for > the general unknown about it. Here is (in Spanish sorry): > http://www.marteens.com/pdfs/TheDarkSideOfDelphi6.pdf > >> >> >> >> >> You CAN do it right. But here I am (right now!) looking at a guy who's >> encoded multi-hundred-line event handlers, that are massive if-then chains, >> with code duplicated like crazy between the events. >> >> >> > > > > hehe, Maybe a sometime when I'm very hurry... but too in Delphi I can use > polimorphic, strategy, double dispatch, etc, for avoid use of if-then. And > no massive code, just necesary code for handle event, just in VisualWorks :) > >> >> >> Really, the "beauty" of the VB model is that you didn't HAVE to learn OO. >> (And, hey, reality bears out that code quality and profit are not strongly >> correlated.) >> >> >>> >>> >>> No. The IDE automaticaly define a global variable and create code for >>> create and assign a instance, but if you want more instances of same Form >>> you can easy declare local variables and create new instance (on initialize >>> of other instance or on the fly in accesor methods) and asign to. Same in >>> Smalltalk.... And you can delete this automaticaly created code. >>> >> >> >> >> >> Sure. You can do a lot of things right. The underlying weakness is in the >> static typing and poorly defined messaging. (I haven't tried FireMonkey yet, >> though, it may be different.) >> > > > > Sure! I completely agree with you. You are deal with reserved words like > "virtual, override, dinamic" for achieve dinamic message dispatch across > static variable typing. This is very inconveniente for clean code (and has > bad psychological consequences in the developers hehe). > I do not try the Embarcadero version (and I do not), but them improved some > things. For example added use de "Class Helper" for do some similar a trait > to a class (but in a context). No only Smalltalk evolves :). FYI see:: > http://edn.embarcadero.com/article/34324 > >> >> >> >> >> >>> >>> >>> mmm no. Again, a Form is not part of model, idealy this is for write >>> event methods handlers. >>> >> >> >> >> >> I'm glad you're following the ideal. I started using Delphi on the beta in >> 1994, and in the past 18 years, I've seen about two instances of the ideal >> being properly followed in the real world (that I didn't write). >> > > > > hehe, again, "the DARK side..." never is very popular. > > >> >> >> >> >>> >>> >>> In the Buttons you can use Actions for delegate the handler method of the >>> click event. In general, you can assign method of a Form to events of >>> controls in another Form, but I do not do often that becouse I only write a >>> small code in the event handler in the Form for delegate to some model the >>> work (DataModules). >>> >> >> >> >> >> Point is: Buttons then become inflexible pass-throughs. In Smalltalk what >> you'd do is allow a component to be swapped for any other component if it >> had the right handlers. >> > > > > In Delphi I can change the component too if they has the right handlers with > out major work, but I agree with you in that this in not possibly do it > easily that in Smalltalk. But, the class of the variable that hold the > current component should be ancestor of both interchangeables components, > very inconvenient! > > >> >> >> >> If you could lay out forms in Smalltalk and press a button to create a >> lean, deployable version, I'd only use Delphi for CPU intensive tasks. >> What'd be optimal is a Smalltalk (with some VA/Delphi influences) in a >> browser with an overall approach like that of OPA or maybe Morfik (not >> Morphic) so that front and back-end stuff was seamless. Smalltalk was born >> for that. >> > > > > > :) > > > > Regards. > GastÃ³n.

Jan. 15, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Gerry Weaver

Hello All, First, let me apologize for starting the Delphi thing. I only mentioned it as an example IDE layout. I was not trying to say that the internal workings of it were good, bad, or indifferent. I have spent some time playing around with things in Pharo. I have been trying to imagine how I would use it on a typical project. I have also been asking myself what it is about the current Smalltalk implementations that are keeping them from being more popular. When I consider the language/environment features that are commonly sited as Smalltalk's strengths, I am surprised that there are so few real world applications out there. I know folks are quick to point to a handful of applications, but the numbers pale in comparison to the mainstream languages. I don't share the same opinion on the productivity of the IDE. It limits my productivity. DISCLAIMER: I am not trying to be critical of Pharo or Smalltalk in general. I am trying to provide some feedback from a Smalltalk newbie that has worked as a professional programmer for many years. I am not trying to push or force my opinion on anyone. I'm just telling it the way I see it. I apologize if anyone is offended by my words. This is certainly not my intention. The following are some thoughts and observations about Smalltalk. 1. I believe Smalltalk's main strength is the language and it's library.Â 2. I don't think the image concept works in the current world. I realize there are many folks who would argue this to death, but the fact is that it hinders adoption. I believe it would be better to focus on a robust full featured library and unload the maintenance of the image based environment. I would think of Smalltalk as a Java alternative.Â 3. I think Smalltalk should probably forget about the desktop gui completely. There are so many good tools to build gui interfaces these days that it would take a huge effort to match even half of the functionality and performance they provide. Smalltalk should focus on rich web interfaces instead. The gui code and tools are stealing valuable resources from development. 4. Developing in Smalltalk should be just like any other high level language. It should have a REPL type interface and it would also be nice to have the capability to compile to a native executable. The various Lisp implementations would be a good example. They too came from a similar environment. 5. It should be possible to embed the Smalltalk VM in other languages (ie; C/C++ etc.) with a nice two-way call interface (think Lua). Â This would allow servers and GUIs written in other languages to leverage Smalltalk for their application logic. 6. The IDE itself would probably be better written in another language. This would ease platform integration, improve performance, and make for a much richer experience overall. My personal choice for this would be Nokia Qt. There is absolutely no reason that the same browser, workspace, transcript based IDE environment wouldn't be possible. This would also pave the way for IDEs like Eclipse, Netbeans, etc. to provide plugins. 7. An interim solution to the items above would be to create a server based interface to the Smalltalk image. This would allow an external IDE to interact with the image in the same way that the embedded tools do. I like the Smalltalk language very much. I think it would make for an awesome embedded scripting language. I also think that it is perfectly suited to hosting the back-end business logic of a large application. I think the best approach for the future is to focus on what Smalltalk would be good at, and not waste valuable resources on things that it is not really the right solution for.Â My personal plan for Smalltalk/Pharo is to create an external IDE and a socket based interface in the Pharo image to support it. I also intend to create an image manager server that can manage, monitor, and communicate with multiple images. I have already been working on an IDE for Lisp. Adding Smalltalk support seems logical.Â Okay.. I've dug my foxhole and I'm in it with my helmet on. Fire away! Thanks, Gerry -----Original Message----- From: "GastÃ³n Dall' Oglio" <gaston.dalloglio(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr Date: 01/14/12 10:06 Subject: Re: [Pharo-project] New IDE alternative (was Misc. newbie questions) Hello Blake. Â Â I like discuss about Delphi, but I don't say much more here becouse this is a Smalltalk list :) 2012/1/13 blake < dsblakewatson(a)gmail.com> Gaston, Â Â Â Â This method is for manage the event, not for do something that is really part of the model. A Form, no is part of the model. This is similar in VW: you coded your event handler method in the AplicationModel, that is like a Form in Delphi. Â Â Â Delphi was a direct reaction to VB, which was eating Borland Pasal's lunch. MVC was nowhere to be seen. It was all about "look how easy it is to do [whatever]." Never "look how easy it is to re-use" or "look how easy it is to maintain". I'm not a Basic basher, but the atmosphere surrounding it has always been "Computer science is =haaaaarrd=. I just wanna program!" Â Â In general, the user of Delphi do not know how to make good programming with it, becouse Delphi granted them make the things quickly and bad. There are a VERY good book named "The dark side of Delphi...", and the DARK word is for the general unknown about it. Here is (in Spanish sorry): http://www.marteens.com/pdfs/TheDarkSideOfDelphi6.pdfÂ Â Â Â You CAN do it right. But here I am (right now!) looking at a guy who's encoded multi-hundred-line event handlers, that are massive if-then chains, with code duplicated like crazy between the events. Â Â Â hehe, Maybe a sometime when I'm very hurry... but too in Delphi I can use polimorphic, strategy, double dispatch, etc, for avoid use of if-then. And no massive code, just necesary code for handle event, just in VisualWorks :) Â Â Really, the "beauty" of the VB model is that you didn't HAVE to learn OO. (And, hey, reality bears out that code quality and profit are not strongly correlated.) Â Â Â No. The IDE automaticaly define a global variable and create code for create and assign a instance, but if you want more instances of same Form you can easy declare local variables and create new instance (on initialize of other instance or on the fly in accesor methods) and asign to. Same in Smalltalk.... And you can delete this automaticaly created code. Â Â Â Sure. You can do a lot of things right. The underlying weakness is in the static typing and poorly defined messaging. (I haven't tried FireMonkey yet, though, it may be different.) Â Â Sure! I completely agree with you. You are deal with reserved words like "virtual, override, dinamic" for achieve dinamic message dispatch across static variable typing. This is very inconveniente for clean code (and has bad psychological consequences in the developers hehe). I do not try the Embarcadero version (and I do not), but them improved some things. For example added use de "Class Helper" for do some similar a trait to a class (but in a context). No only Smalltalk evolves :). FYI see:: http://edn.embarcadero.com/article/34324Â Â Â Â Â Â mmm no. Again, a Form is not part of model, idealy this is for write event methods handlers.Â Â Â Â I'm glad you're following the ideal. I started using Delphi on the beta in 1994, and in the past 18 years, I've seen about two instances of the ideal being properly followed in the real world (that I didn't write). Â Â hehe, again, "the DARK side..." never is very popular. Â Â Â Â Â In the Buttons you can use Actions for delegate the handler method of the click event. In general, you can assign method of a Form to events of controls in another Form, but I do not do often that becouse I only write a small code in the event handler in the Form for delegate to some model the work (DataModules). Â Â Â Point is: Buttons then become inflexible pass-throughs. In Smalltalk what you'd do is allow a component to be swapped for any other component if it had the right handlers. Â Â In Delphi I can change the component too if they has the right handlers with out major work, but I agree with you in that this in not possibly do it easily that in Smalltalk. But, the class of the variable that hold the current component should be ancestor of both interchangeables components, very inconvenient! Â Â Â If you could lay out forms in Smalltalk and press a button to create a lean, deployable version, I'd only use Delphi for CPU intensive tasks. What'd be optimal is a Smalltalk (with some VA/Delphi influences) in a browser with an overall approach like that of OPA or maybe Morfik (not Morphic) so that front and back-end stuff was seamless. Smalltalk was born for that. Â Â Â :) Â Â Regards. GastÃ³n.

Jan. 15, 2012

[Pharo-project] Bug in pharo image

by Garret Raziel

Hi, I think I found bug in pharo image. I would post it in bug tracker but I don't know if it is not duplicate to this bug http://code.google.com/p/pharo/issues/detail?id=3349&can=1&q=ConnectionQueu…. If you create ConnectionQueue to listen to some port, send it message "getConnectionOrNil" and there IS connection, debuger pops out with "MessageNotUnderstood True>>isConnected". I searched through code and obviously it is problem in ConnectionQueue>>listenLoop, that sends bad message to socket (Socket>>waitForConnection:), that returns true or false, not connection itself. It is works in squeak image. Should I post it to bugtracker? Or am I wrong? And isn't it duplicate to that link? Thanks, Jan

Jan. 14, 2012

Re: [Pharo-project] executing a script in headless mode?

by Bernardo Ezequiel Contreras

i try it again with the last image #14283 and it doesn't work On Sat, Jan 14, 2012 at 4:12 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > > On 14 Jan 2012, at 19:28, Bernardo Ezequiel Contreras wrote: > > > file://home/vonbecmann/pharo-projects/trunk/set-up.st > > /home/vonbecmann/pharo-projects/trunk/set-up.st should work just as well. > > > >

Jan. 14, 2012

[Pharo-project] [update 1.4] #14284

by StÃ©phane Ducasse

14284 ----- - Issue 5175: CommandLine args not working. Thanks Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=5175 - Issue 5171: Remove styling from PreDebug warning message. Thanks Guillermo Polito. http://code.google.com/p/pharo/issues/detail?id=5171 - Issue 5165: Incorporate to Pharo DisplayScreen options. Thanks Esteban Lorenzano. http://code.google.com/p/pharo/issues/detail?id=5165 Thanks a lot guys for your good energy. I need it. Stef

Jan. 14, 2012

Re: [Pharo-project] Design change possible with fast SSD's possible?

by Michael Haupt

Hi Stefan, Am 14.01.2012 um 19:56 schrieb Stefan Marr <smalltalk(a)stefan-marr.de>: > Just tell your OS to use your SSD as swap drive, and you got what you want. > Without any VM changes. that's a nice way to see a Smalltalk image with its contents frequently moving about due to GC ... ;-) Best, Michael

Jan. 14, 2012

Re: [Pharo-project] [Interesting] Drive to remove unused code in LibreOffice

by Igor Stasenko

On 14 January 2012 20:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jan 14, 2012, at 12:55 PM, Sven Van Caekenberghe wrote: > >> >> http://www.i-programmer.info/news/136-open-source/3607-drive-to-remove-unus… >> >> probably a problem in every large code base > > :) > > so a lot of energy to get it done. Now this should be easier for them because they should not have users and extender of their system. > > yes, i think it is easier for them, because they don't have to be a 'general purpose' environment. OpenOffice has a list of features they care of, and for anything which doesn't fits in that niche, they can throw it out without a lot of consideration. -- Best regards, Igor Stasenko.

Jan. 14, 2012

Re: [Pharo-project] Saga of trying to integrate IDE with OpenGL continuesRe: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?

by Lawson English

Sounds good. BTW, the trend of popularity continues. This latest video http://www.youtube.com/watch?v=F5GHRaIwCS4 has had 45 views since I put it up yesterday and the first video on that topic is now at 145 views (my most popular video took 2 months to get that many views). Once you get NBOpenGL and GLDisplay cross-platform, I suspect there will be a rather large number of OpenGL programmers testing how it works. Games, GUI testing, algorithmic and other technical visualization. Cobalt/Croquet integration, etc. Lots of potential here. L. On 1/14/12 7:22 AM, Igor Stasenko wrote: > On 14 January 2012 07:12, Lawson English<lenglish5(a)cox.net> wrote: >> http://www.youtube.com/watch?v=F5GHRaIwCS4 >> >> nowhere near where it could be. With NBOpenGL and GLDisplay, things would be >> much snappier and easier. Of course, at this point, we need to start >> discussing how to integrate OpenGL errors into the squeak debugging system >> so that the IDE remains stable... >> > well, one of the ideas is to use fallback display in case of openGL error(s). > And render not to GL context but to bitmap. Then you can actually use > debugger to debug GL calls step by step > without interfering with GL stack/state. > Another approach would be to create a separate GL context and use it > for debugger. But then you need to keep an eye > for switching active contexts at right moment. > >> L. >>

Jan. 14, 2012