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

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

by Gerry Weaver

Hi Jimmie, Good stuff!! Thanks so much for taking the time to read and reply to my post. Any and all feedback is welcome and appreciated. Thanks Again, Gerry -----Original Message----- > From: "Jimmie Houchin" <jlhouchin(a)gmail.com> > To: pharo-project(a)lists.gforge.inria.fr > Date: 01/15/12 19:44 > Subject: Re: [Pharo-project] New IDE alternative (was Misc. newbie questions) > > On 1/15/2012 6:55 AM, Gerry Weaver wrote: > > 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. > > And I have to disagree with you here. You lack the imagination and > knowledge to understand the significant advantage of having a single > language, environment and toolset that Smalltalk provides. > > >> 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. > > Again, I think you lack imagination. You are stuck in box built by all > your previous tools and experience. And from your box you are trying to > look at Smalltalk and trying to shape it to your experience and thusly > declaring its deficiencies. This does not make Smalltalk wrong. > > Most of us here like the Smalltalk experience. We like the language. We > like the image. Are there issues that we would like to overcome? Of > course. Outside of interfacing with the outside world being made easier, > I don't think you are really addressing those issues. Instead, your are > creating issues we don't have. And many of us find many things we can do > living in our world and slowly working on what our world can access. > > If you want to mold Pharo into the image that you think it should be. > Please feel free to do so. It is open source. Fork it and make it so. We > would even help where we are able. But you are going outside of the > vision and worldview of this community and most any Smalltalk community. > > Cincom, Gemstone, or any of the other commercial Smalltalks have > reasonable success despite all the deficiencies you have discovered. > > And if you decide that Smalltalk doesn't fit your worldview. That is ok. > Find the tool that fits you. Be productive with it. And if you want to > create what you think is a better way with what you learn from > Smalltalk. Go for it. > > As far as GUI. I like ours. I think it can be improved greatly. But I > like access to it as part of my environment. > > What is a standard UI? Who set this standard? Why is QT standard? or > WxWidgets or ...? Look at the most used apps out there. Are they using > native standard UI? I don't think so. iTunes is a hugely used app. Is it > standard UI? No. Apple Mail? Safari? Windows Media player? No these > things are used by most of the computing world and they don't even use > the normal standard native UI of their platform. And they are all ugly. > > Is Facebook standard? Web apps are used all the time. > > Who says what is standard. And is what is standard today, what we should > strive for? Or can we work towards a better future. > > I use all kinds of applications which do not meet your standard of being > a native standard UI. But I use them. Why? Because they provide the > abilities to do what I want or need. Not because they meet any > particular standards as defined by nameless potentially clueless people. > > So more than meeting any particularly defined standard of UI, what is > required is than an application be compelling. If it is not, then no > matter how standards compliant it will meet with little receptiveness. > > Is Eclipse, Netbeans, Vi, Emacs standard. Windows or Mac? If Windows, > XP, Vista, 7, 8? What is standard on Linux? KDE, Gnome, Unity, pick your > favorite WM. So why is it your developers get to use non-standard tools, > (Emacs, Vi), or define then standard as being what they use? > > There are lots of applications where the UI is almost never standard by > anyone's definition. In my world financial investment apps. Education > apps, games, ... > > This argument passes no reasonable standard. > > >> 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). > > So, in this statement, by definition you are moving from the most > standard defined UI to lesser standard UIs. Linux is all over the map. > > The above are simply my opinions and I make no express statements that > anyone else in the Pharo community agrees with them. > > Personally I am all for improving the Pharo worlds and making more > things accessible within that world. Not necessarily becoming like the > world outside of Pharo/Smalltalk. If I want that world, it is already there. > > I would also presume that by your exploration of our little world, which > by the way is 30+ years old, that you have sufficient deficiencies in > the world you come from to explore what else is available. > > Jimmie

Jan. 16, 2012

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

by Schwab,Wilhelm K

I don't just write English, I also write Smalltalk :) I had put some related code on SqueakMap, but I suspect it disappeared in one of the meltdowns. It also picked up some code that I had not intended to release, which led me to be unhappy with http repositories. The code varies in quality, covering things missing in streams, FFI, value adapters, among other things. I recently noted that the FFI code will require tweaking to be of use with 1.3 and up. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Sunday, January 15, 2012 3:47 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] reading *exactly* n bytes from socket On Jan 15, 2012, at 9:19 PM, Max Leske wrote: > Good to know, that you're working on it. Took me a while to figure out that #next: would not fill the entiry bufferâ¦ I'm not. I just know that bill tried to explain to us what was the problem :) and since the emails/sentences were too long or too english I was always lost but I know that there is this point that we should address. > > Unfortunately, I wasn't able to resolve my afore mentioned problem completely. To make things easier, I sent #upToEnd to my SocketStream, expecting to get all the data (and then read the lines later). However, towards the end of the transmission the connection is suddenly closed (ConnectionClosed is signaled by Socket>>waitForDataFor:) and I lose a variable amount of data (up to about 300KB out of 4.7MB). The primitive says that the server closed the connection (which might of course be true) but I can't see where my data went missing. > > In one case I even had a singel byte missing inside a line (the line was one byte shorter than advertised). Now this would probably be a totally different proplem and, to be fair, I couldn' reproduce it, so ignore this for now. > > Camillo is now looking into ithe SocketStream stuff but if any of you have a clue what could be going on, I'd appreciate your help. > > Cheers, > Max > > On 15.01.2012, at 20:56, StÃ©phane Ducasse wrote: > >> >> On Jan 15, 2012, at 8:10 PM, Schwab,Wilhelm K wrote: >> >>> Max, >>> >>> I wouldn't forget it too soon. Streams should work as advertised or raise an error. My (compromise) proposal remains as follows: >>> >>> http://code.google.com/p/pharo/wiki/StreamsForRobustSoftware >> >> Yes :) >> >> I know. >> >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Max Leske [maxleske(a)gmail.com] >>> Sent: Sunday, January 15, 2012 6:18 AM >>> To: pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] reading *exactly* n bytes from socket >>> >>> 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. 16, 2012

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

by Jimmie Houchin

On 1/15/2012 6:55 AM, Gerry Weaver wrote: > 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. And I have to disagree with you here. You lack the imagination and knowledge to understand the significant advantage of having a single language, environment and toolset that Smalltalk provides. >> 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. Again, I think you lack imagination. You are stuck in box built by all your previous tools and experience. And from your box you are trying to look at Smalltalk and trying to shape it to your experience and thusly declaring its deficiencies. This does not make Smalltalk wrong. Most of us here like the Smalltalk experience. We like the language. We like the image. Are there issues that we would like to overcome? Of course. Outside of interfacing with the outside world being made easier, I don't think you are really addressing those issues. Instead, your are creating issues we don't have. And many of us find many things we can do living in our world and slowly working on what our world can access. If you want to mold Pharo into the image that you think it should be. Please feel free to do so. It is open source. Fork it and make it so. We would even help where we are able. But you are going outside of the vision and worldview of this community and most any Smalltalk community. Cincom, Gemstone, or any of the other commercial Smalltalks have reasonable success despite all the deficiencies you have discovered. And if you decide that Smalltalk doesn't fit your worldview. That is ok. Find the tool that fits you. Be productive with it. And if you want to create what you think is a better way with what you learn from Smalltalk. Go for it. As far as GUI. I like ours. I think it can be improved greatly. But I like access to it as part of my environment. What is a standard UI? Who set this standard? Why is QT standard? or WxWidgets or ...? Look at the most used apps out there. Are they using native standard UI? I don't think so. iTunes is a hugely used app. Is it standard UI? No. Apple Mail? Safari? Windows Media player? No these things are used by most of the computing world and they don't even use the normal standard native UI of their platform. And they are all ugly. Is Facebook standard? Web apps are used all the time. Who says what is standard. And is what is standard today, what we should strive for? Or can we work towards a better future. I use all kinds of applications which do not meet your standard of being a native standard UI. But I use them. Why? Because they provide the abilities to do what I want or need. Not because they meet any particular standards as defined by nameless potentially clueless people. So more than meeting any particularly defined standard of UI, what is required is than an application be compelling. If it is not, then no matter how standards compliant it will meet with little receptiveness. Is Eclipse, Netbeans, Vi, Emacs standard. Windows or Mac? If Windows, XP, Vista, 7, 8? What is standard on Linux? KDE, Gnome, Unity, pick your favorite WM. So why is it your developers get to use non-standard tools, (Emacs, Vi), or define then standard as being what they use? There are lots of applications where the UI is almost never standard by anyone's definition. In my world financial investment apps. Education apps, games, ... This argument passes no reasonable standard. >> 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). So, in this statement, by definition you are moving from the most standard defined UI to lesser standard UIs. Linux is all over the map. The above are simply my opinions and I make no express statements that anyone else in the Pharo community agrees with them. Personally I am all for improving the Pharo worlds and making more things accessible within that world. Not necessarily becoming like the world outside of Pharo/Smalltalk. If I want that world, it is already there. I would also presume that by your exploration of our little world, which by the way is 30+ years old, that you have sufficient deficiencies in the world you come from to explore what else is available. Jimmie

Jan. 16, 2012

[Pharo-project] [ANN] Amber Smalltalk 0.9.1 is out!

by Nicolas Petton

About 4 moons have passed and Amber - the Smalltalk for the web - has during that time moved forward quite a lot. Since the 0.9 release back in september we have made about 250 commits and closed 52 issues of about 75 reported during these months. Now with over 43 forks on github and more than 230 followers the project: http://www.amber-lang.net ...is live and kicking! A lot of cool stuff is being done in those forks and not in the master repository, like for example the gaming framework called Ludus by Bernat Romagosa: https://github.com/bromagosa/amber/tree/ludus ...or Ambrhino by Stefan Krecher - Amber running in Rhino: https://github.com/StefanKrecher/Ambrhino So, why would you take a look at Amber? In our opinion Amber is perfectly positioned for the HTML5 onslaught and the explosion of all-things-javascript like for example Nodejs. Amber plays very well with others and can seamlessly use Javascript libraries! It's a *real* Smalltalk, the environment is all there including Workspace, Transcript, Browser, senders/implementors/references to class, TestRunner, Inspectors, code editing with syntax coloring and a Debugger. There is no image or interpreter, all compilation is incremental. JavaScript is quite a broken language with lots of traps and odd quirks. It is the assembler of the Internet and we love it for that, but we don't want to write applications in it. Smalltalk is immensely cleaner, both syntactically and semantically with a simple class model and a lightweight syntax for closures. It is in many ways a perfect match for the Good Parts of JavaScript. And having a true live interactive incremental development environment where you can build your application directly in the browser is unbeatable... Below follows a summary of the major changes since release 0.9. We hope you join us in developing Amber and having fun! Fork at github, join in #amber-lang on freenode and hop onto the mailing list. regards, Nicolas & GÃ¶ran ...and a BIG thanks to everyone that are involved in the project! --------------------------------------------- Here's a summary of changes since the 0.9 release: - 80 new unit tests written - 52 issues fixed - All classes in Kernel-Objects, Kernel-Classes and Kernel-Methods has been documented - New documentation framework (see http://amber-lang.net/documentation.html) - Better class organisations, "Kernel" package split into several packages - First class packages have replaced class categories - Internet Explorer 7+ compatibility - New Announcement framework ported from Pharo - New console-based REPL written in Amber using node.js - Symbol class implemented together with object identity and #== - New OrderedCollection and Set implementation - Dictionary can now have any kind of object as keys. String-key dictionary has been renamed HashedCollection - New TwitterWall example - Improved HTML Canvas, now compatible with IE7 - Improved JSObjectProxy for seemless JavaScript objects access from Amber - No more jQuery binding. Amber is fully capable of sending messages to JavaScript objects

Jan. 16, 2012

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

by blake

On Sat, Jan 14, 2012 at 8:22 PM, Gerry Weaver <gerryw(a)compvia.com> wrote: > 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 think there's a lot to be learned there but, of course, I would. >>1. I believe Smalltalk's main strength is the language and it's library. Language, yes. Library? Seems unlikely. The core libraries are cool but overall the efforts of more popular languages positively dwarf ST's. >> 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. Java was alternative to Smalltalk. The image concept works, it's just too murky. >>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. Open Source: People do what they want to do. Even if you stopped people from doing GUIs, they wouldn't necessarily shift to doing what you want. >>4. Developing in Smalltalk should be just like any other high level language. Then why have it? Just for the syntax? >>It should have a REPL type interface Workspace/Transcript? ===Blake===

Jan. 15, 2012

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

by Lawson English

A remote squeak image that is used to handle OpenGL calls (or other external lib calls) and pass error codes back to the main IDE might be useful for OpenGL (or other external lib) debugging. VM support could be made so that error checking could be handled below the level of the interpreter for maximum speed. A lot can be done if Spoon is ever officially embraced by the meta-squeak community (Pharo and Squeak are thus far the only members that I am aware of). L. On 1/15/12 11:54 AM, Igor Stasenko wrote: > Guys, the best thing what can be done is to sit and write down new > GUI/IDE/remote tools/whatever will make your joy with > smalltalk greater. > Talking endlessly "how better it would be if there be ... " is just > waste of time. > > my 2 cents. >

Jan. 15, 2012

Re: [Pharo-project] Finding all places where a class is instantiated?

by Lawson English

Don't all eventually use #basicNew ? On 1/15/12 11:39 AM, Igor Stasenko wrote: > just keep in mind that some classes do not instantiating using #new >

Jan. 15, 2012

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

by StÃ©phane Ducasse

On Jan 15, 2012, at 9:19 PM, Max Leske wrote: > Good to know, that you're working on it. Took me a while to figure out that #next: would not fill the entiry bufferâ¦ I'm not. I just know that bill tried to explain to us what was the problem :) and since the emails/sentences were too long or too english I was always lost but I know that there is this point that we should address. > > Unfortunately, I wasn't able to resolve my afore mentioned problem completely. To make things easier, I sent #upToEnd to my SocketStream, expecting to get all the data (and then read the lines later). However, towards the end of the transmission the connection is suddenly closed (ConnectionClosed is signaled by Socket>>waitForDataFor:) and I lose a variable amount of data (up to about 300KB out of 4.7MB). The primitive says that the server closed the connection (which might of course be true) but I can't see where my data went missing. > > In one case I even had a singel byte missing inside a line (the line was one byte shorter than advertised). Now this would probably be a totally different proplem and, to be fair, I couldn' reproduce it, so ignore this for now. > > Camillo is now looking into ithe SocketStream stuff but if any of you have a clue what could be going on, I'd appreciate your help. > > Cheers, > Max > > On 15.01.2012, at 20:56, StÃ©phane Ducasse wrote: > >> >> On Jan 15, 2012, at 8:10 PM, Schwab,Wilhelm K wrote: >> >>> Max, >>> >>> I wouldn't forget it too soon. Streams should work as advertised or raise an error. My (compromise) proposal remains as follows: >>> >>> http://code.google.com/p/pharo/wiki/StreamsForRobustSoftware >> >> Yes :) >> >> I know. >> >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Max Leske [maxleske(a)gmail.com] >>> Sent: Sunday, January 15, 2012 6:18 AM >>> To: pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] reading *exactly* n bytes from socket >>> >>> 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] reading *exactly* n bytes from socket

by Max Leske

Thanks Sven, I'll give it a shot. Max On 15.01.2012, at 21:26, Sven Van Caekenberghe wrote: > > On 15 Jan 2012, at 21:19, Max Leske wrote: > >> Camillo is now looking into ithe SocketStream stuff but if any of you have a clue what could be going on, I'd appreciate your help. > > Have a look at Zodiac too, although it is an implementation of a secure socket stream, it also contains different re-implementations of SocketStream, because I found the existing one to be too hard to subclass. In terms of API and behavior, it does try to mimic the original of course. > > Sven

Jan. 15, 2012

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

by Sven Van Caekenberghe

On 15 Jan 2012, at 21:19, Max Leske wrote: > Camillo is now looking into ithe SocketStream stuff but if any of you have a clue what could be going on, I'd appreciate your help. Have a look at Zodiac too, although it is an implementation of a secure socket stream, it also contains different re-implementations of SocketStream, because I found the existing one to be too hard to subclass. In terms of API and behavior, it does try to mimic the original of course. Sven

Jan. 15, 2012