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

Re: [Pharo-project] Method recategorization proposal for TestCase class

by Alexandre Bergel

> I was trying to measure coverage of my code http://hapao.dcc.uchile.cl Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 15, 2012

[Pharo-project] Method recategorization proposal for TestCase class

by NicolÃ¡s Paez

Hi people, I was trying to measure coverage of my code and I realized the method *TestCase class>>packageNamesUnderTest* belogs to a category called **sunitgui*, *shouldn't it belong to coverage category?* I was about opening an issue for this, but I wanted to check it first because maybe there is a reason I don't understand. Regards, Nico. blog: nicopaez.wordpress.com

Jan. 15, 2012

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

by Alexandre Bergel

Everything depends on what do you need Smalltalk for. Pharo fits my need perfectly. The image and having the IDE running in the same memory than the application are the most important assets for what I use Smalltalk everyday. It is like saying that a particular place X is the best place to go for holidays... Well... it may depend on whether you prefer trekking or diving. Cheers, Alexandre On 15 Jan 2012, at 01:22, 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> > 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. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 15, 2012

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

by Gerry Weaver

Hi Andreas, Â >I am not comfortable with the idea to write parts of an application in different languages. >Typically the disadvantages overweigh the advantages to do so as you would have different languages and systems to master >and update. >Interoperability with other systems and languages should be easy and Squeak/Pharo are still lacking in this area. This is well >known and hopefully there will be some improvements in the future. I guess I would have to disagree with you here. Most of the editors and IDEs of other languages are not maintained by the language proper. There are many editors and IDEs that support many languages in addition to the one they are written in. I think the benefits of using a full featured GUI toolkit to create an IDE would be significant. Â >Planning to give up on parts like GUI is a bad idea in my opinion. Smalltalk would be even more niche than it is now. I want >to be able to build complete applications without theÂ need to build parts in another language. In theory I would agree with you. However, I wasn't able to come up with an application scenario where the Pharo GUI would work. Either the widget set and OS integration are too limited or performance is a problem. For example, the last several applications I have done needed to display PDF files. I have done a little testing with Pharo and I'm sorry to say the results were not very encouraging. Â The problem I think is one of limited resources. I think that maybe trimming some things would render more progress on the core. Perhaps a good and complete binding to one of the current GUI toolkits would be easier to maintain. You would also get the instant advantage of everything the toolkit had to offer (including performance). A more robust FFI would inevitably be realized as a result.Â >Especially having the IDE in Smalltalk itself and thus being able to inspect and debug and modify everything is a big advantage >over any IDE in a different language. I don't understand why the IDE needs to be in the image/language to do that. Â >All Smalltalk implementations have shortcomings in some areas. There are a multitude of reasons for it, be it commerciallyÂ >(greater estimated expenses than earnings from it) or just lack ofÂ capacity. Smalltalk users are rare these days and the >community is split because of different implementations and interests.Â For me, Pharo is on a good way to take the Smalltalk >language into a better ecosystem. Â But for the moment Dolphin Smalltalk is my preferred system because it's relatively cheap >andÂ has only few known bugs. In my eyes it deserves a bigger community and better commercial success. But I guess that's >what every Smalltalker thinks about his preferred Smalltalk system... Dolphin seems to be one of the better implementations, but the problem with Dolphin is Windows. All of the projects on my radar right now are moving applications away from Windows to Mac/Linux (mostly Mac). Thanks, Gerry

Jan. 15, 2012

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

by Gerry Weaver

Hello All, I think I have delivered the message that I intended to. Perhaps this thread has run it's course. I appreciate y'all taking the time to respond. The information you provided has been helpful. I have taken another look at the Smalltalk XY project. It pretty much does everything I need. I would be picking up around 12k lines of C code to maintain, but the code looks to be fairly clean and portable. I may start my little project with that. I don't get the impression there is very much interest in the things that I've mentioned here. Anyway, it may turn out to be kind of fun to tweak things in a Smalltalk VM ;-)Â Thanks Again, Gerry

Jan. 15, 2012

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

by Andreas Wacknitz

Am 15.01.2012 um 12:11 schrieb Gerry Weaver: > Hi Andreas, > > >you are always writing "Smalltalk IDE". Which Smalltalk variants do you know? Squeak and Pharo are not the only ones. There >are some others, some commercial and some free. > >If you haven't any experiences with them yet you should at least have a look at them. > > I have looked at Squeak, Pharo, Dolphin, VisualWorks, and VA. I am generalizing, because they all have the things that I find problematic. I also looked at GNU, but I don't like the whole GNU license thing very much. The one that comes the closest to what I'm thinking about is something called Smalltalk XY (not Smalltalk/X), but it is no longer maintained. I am more than happy to learn. Are there any others I should check out? > None that I know of. I am not comfortable with the idea to write parts of an application in different languages. Typically the disadvantages overweigh the advantages to do so as you would have different languages and systems to master and update. Interoperability with other systems and languages should be easy and Squeak/Pharo are still lacking in this area. This is well known and hopefully there will be some improvements in the future. Planning to give up on parts like GUI is a bad idea in my opinion. Smalltalk would be even more niche than it is now. I want to be able to build complete applications without the need to build parts in another language. Especially having the IDE in Smalltalk itself and thus being able to inspect and debug and modify everything is a big advantage over any IDE in a different language. In the end one of the big difference between Smalltalk and most other languages is the living object world. It might be interesting to find new ways of having it (and thus leaving the image behind), but what mainstream languages offer these days would be a step back. All Smalltalk implementations have shortcomings in some areas. There are a multitude of reasons for it, be it commercially (greater estimated expenses than earnings from it) or just lack of capacity. Smalltalk users are rare these days and the community is split because of different implementations and interests. For me, Pharo is on a good way to take the Smalltalk language into a better ecosystem. But for the moment Dolphin Smalltalk is my preferred system because it's relatively cheap and has only few known bugs. In my eyes it deserves a bigger community and better commercial success. But I guess that's what every Smalltalker thinks about his preferred Smalltalk system... Regards, Andreas

Jan. 15, 2012

Re: [Pharo-project] reading *exactly* n bytes from socket

by Max Leske

Sorry, forget what I just wroteâ¦ I found the bug in my code. Should have checked if the connection is still open :-/ Cheers, Max On 15.01.2012, at 12:09, Max Leske wrote: > Hey guys > > I'm having a problem with Socket / SocketStream. When I know that the next packet of data from the server is going to be 10'000 bytes I want to ask the socket for exactly 10'000 bytes of data (I don't care how long it takes). However, the comments in the Socket class suggest that the buffer might not be filled entirely when the message answers. As a consequence, my code fails because the ByteArray sometimes has a number of zero bytes at the end which obviously wasn't expected. > I also tried to use SocketStream to get around this problem but wasn't successful. Am I supposed to handle this case myself or did I overlook something? > > Cheers, > Max

Jan. 15, 2012

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

by Gerry Weaver

Hi Andreas, >you are always writing "Smalltalk IDE". Which Smalltalk variants do you know? Squeak and Pharo are not the only ones. There >are some others, some commercial and some free. >If you haven't any experiences with them yet you should at least have a look at them. I have looked at Squeak, Pharo, Dolphin, VisualWorks, and VA. I am generalizing, because they all have the things that I find problematic. I also looked at GNU, but I don't like the whole GNU license thing very much. The one that comes the closest to what I'm thinking about is something called Smalltalk XY (not Smalltalk/X), but it is no longer maintained. I am more than happy to learn. Are there any others I should check out? Thanks, Gerry

Jan. 15, 2012

[Pharo-project] reading *exactly* n bytes from socket

by Max Leske

Hey guys I'm having a problem with Socket / SocketStream. When I know that the next packet of data from the server is going to be 10'000 bytes I want to ask the socket for exactly 10'000 bytes of data (I don't care how long it takes). However, the comments in the Socket class suggest that the buffer might not be filled entirely when the message answers. As a consequence, my code fails because the ByteArray sometimes has a number of zero bytes at the end which obviously wasn't expected. I also tried to use SocketStream to get around this problem but wasn't successful. Am I supposed to handle this case myself or did I overlook something? Cheers, Max

Jan. 15, 2012

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

by Gerry Weaver

Hi Andreas, >Proposals like yours aren't new. In fact there are also complementary proposals like "give up that strange syntax and introduce >curly braces...". >Combined that will lead to either C# or Java. Â I am not advocating any changes to the language. >From your ideas I only like the enhancements for Squeak's and Pharo's interfacing to non Smalltalk libraries. >All others will only weaken Smalltalk's strengths (even if you don't realize that yet). I definitely see strengths in the Smalltalk language. I just think it needs to be made accessible to a broader audience.Â >If you are not only developing web applications or server only applications then you might want to have a look at Dolphin >Smalltalk in order to see a decent Smalltalk IDE. >The free community edition lacks some of the tools (system browser and idea space) but still you will get an idea of what is >possible. I am not really making a proposal and I'm not trying to influence Pharo/Smalltalk. I DO respect everyone's opinion. I am just discussing the things that I find difficult about using Smalltalk on a real world project. I don't know for sure, but maybe if comments like mine keep coming up, then some of them should be given more thought. It must be possible that some of them could be answered without changing Pharo/Smalltalk as a language. After all, there has to be a reason that more people don't use Smalltalk. Â I came to Pharo, because of the advertised focus on making a Smalltalk implementation that is more geared towards commercial applications. I am providing feedback that I feel directly targets that specific area. Â It's interesting to me how everyone seems to think that the IDE IS the language. I don't think that at all. I also don't think that there is any reason to get rid of the IDE. However, I don't see why there should be a problem with having some alternatives. Thanks, Gerry

Jan. 15, 2012