June 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] 1.3 profiler - nice stuff!

by Schwab,Wilhelm K

Recent mention of the profiler prodded me to take a look at the profiler in 1.3. Very nice! Some "quick" changes that I think would be good: (1) Shout in the code pane; (2) Use tabs to show the gc data or the code; (3) Add a tab to show the result rather than using a modal notifier (which probably quickly gets dismissed, and then missed<g>). A non-quick change, if it's even possible... Some of the slickest Dolphin goodies in existence include: Ian Bartholomew's ChunkBrowser (Pharo's lost changes is close and useful, but not the same) and Profiler, the SUnitBrowser (nicer than the SUnit test runner), and Ghoul. Ghoul is well named. It presents Dolphin crash dumps in a debugger-like view: http://metagnostic.org/DolphinSmalltalk/Ghoul.html If there is, or could/should be enough data in a profile to do the same thing, it would make an interesting addition. Then interacting with the code includes the ability to see the values of variables. Bill

June 30, 2011

Re: [Pharo-project] little challenge for sven and us

by Norbert Hartl

Am 30.06.2011 um 21:03 schrieb Janko MivÅ¡ek: > > > S, Norbert Hartl piÅ¡e: >> >> Am 30.06.2011 um 17:53 schrieb Janko MivÅ¡ek: >> >>> S, Norbert Hartl piÅ¡e: >>> >>>> Am 30.06.2011 um 17:23 schrieb StÃ©phane Ducasse: >>> >>>>>>> apparently people get excited by nodeJS and I would like to know the equivalence of >>> >>>>>> What does it mean? >>> >>>>> in Pharo.. how do you have the same: >>> >>>> It depends what is in your head when you wrote this. The code snippet doesn't tell that much. Registering a Block for execution on request is probably not what makes you excited about. What is exciting about it is that javascript is written in a strictly asynchronous manner (event driven) and that matches perfectly the implementation with asynchronous I/O. Suddenly you can write programs they way you ever wanted it. And lucky for us smalltalk itself is event driven so it can go there easily, too. Well, easily would mean to have support for asynchronous I/O in the vm (file operations) and in the socket plugin at least. >>> >>> Because I'm just working on asynchronous no-blocking node.js like >>> control flow in Aida, I can say that this is really natural to Smalltalk >>> with its closures, much more than so called callbacks in JavaScript. In >>> Smalltalk it is more readable and you hardly notice the difference to >>> the normal Smalltalk code, while in JavaScript those callbacks are a bit >>> hard to grasp and understand. From non seasoned programmer perspective, >>> that is. >>> >> Can you elaborate on this? I agree that one of the biggest flaws in javascript is that you have to write function() {} to use a closure which prevents its usage in a lot of cases, e.g. in filter functions etc. It is just ugly and nobody likes it. The second point is that you need to preserve this in javascript manually if you wish to use it in closures. >> Apart from that I can see a single difference between the two. Callbacks are natural to javascript because most usage pattern use it. Closures are natural to smalltalk because it just needs [ ] and it is well used throughout the class library. > > Let me show an example by Ryan Dahl, author of node.js. First in > JavaScript then how it will look in Smalltalk. > > Synchronous blocking database call: > > var result = db.query("select.."); > // wait > // use result > > Asynchronous non-blocking database call: > > db.query("select..", function (result) {// use result }); > // continue > > In first case program execution is blocked until database returns > result. In second case we register a callback function to deal with the > result. This function will be called later when result arrives, while we > don't wait but continue with execution. > > If you'll do in Smalltalk a blocking call: > > result := db query: 'select..'. > result useIt > > A non-blocking call can look something like: > > db query: 'select..' thenDo: [:result | result useIt ] > > As you see with our closures we can much more naturally and > understandably write such calls. > Ok, I don't think we need to argue that smalltalks syntax has great potential. But to be honest > db query: 'select..' thenDo: [:result | result useIt ] doesn't feel natural to me from a smalltalk point of view. More natural appears database select: [:each| each....] So not having to use javascript syntax might be an advantage. It would be great if you would omit the SQL as well ;) If we talk about asynchronous programming I'm more concerned about composability and control of asynchronous operations then to have a nice syntax for a really simple case. Norbert

June 30, 2011

Re: [Pharo-project] Please test Pharo 1.3!

by Mariano Martinez Peck

On Tue, Jun 28, 2011 at 1:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Nice to see 1.3 coming forward! > > I don't have thorough test results from real experience using 1.3, but just > some remarks from randomly testing the tools for 20 or so minutes: > > - Script Manager is broken: adding a script produces an error > Torsten, can you take a look? > - Transcript: I do "Transcript show: 'hello'" but nothing happens. > Strange... So I click on the icons in the bottom bar, noting happens either. > So I click in the main pane and get an error (errorSubscriptBounds:). Not > sure how the new Transcript is supposed to be used... > yes, I reported this and it was fixed. > - Undo with cmd-shift-z doesnt work anymore (und from the context menu > works, however) > > cmd-shift-z or cmd+z? it works correctly here with cmd+z > Minor stuff I noticed: > - In world menu, class browser doesn't have an icon > - MC browser and some other tools have buttons with a blue top shade, while > other tools don't > - Recent submissions has syntax highlighting enabled for class comments > ben, can you take a look? > - The top right scroll pane of the Test Runner is too high > - The bottom pane with the buttons of the Test Runner is too high > > Since I haven't worked with 1.3 yet, I can't tell about all the cool new > stuff and cleanups yet. (Except for the Time Profiler I tried out, which is > very cool!) > > it would be nice to create issues for the rest... cheers > HTH, > Adrian > > > On Jun 28, 2011, at 12:14 , Janko MivÅ¡ek wrote: > > > Hi Marcus, > > > > Aida works ok. One suggestion: put version number somewhere near Pharo > > logo in main window. Otherwise is pretty hard to recognize on which > > image version you are working. > > > > Or maybe introducing Help -> About in world menu? Or both... > > > > Thanks and best regards > > Janko > > > > S, Marcus Denker piÅ¡e: > >> Please test Pharo 1.3! > >> > >> There is no magic.. what is now here: > >> > >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.3/ > >> > >> Will be the release. Issues fixed until the released are just those that > will be detected and fixed. > >> > >> There is no magic. > >> > >> For those who only run released software: Version Number is 1.3. > Consider this released. There will be no RC. > >> > >> Marcus > >> > >> -- > >> Marcus Denker -- http://www.marcusdenker.de > >> INRIA Lille -- Nord Europe. Team RMoD. > >> > >> > >> > > > > -- > > Janko MivÅ¡ek > > Svetovalec za informatiko > > Eranova d.o.o. > > Ljubljana, Slovenija > > www.eranova.si > > tel: 01 514 22 55 > > faks: 01 514 22 56 > > gsm: 031 674 565 > > > > > -- Mariano http://marianopeck.wordpress.com

June 30, 2011

Re: [Pharo-project] little challenge for sven and us

by StÃ©phane Ducasse

> That's not really a challenge ;-) Excellent I like to hear that :) Now we should add it on the web somewhere because this is the second lesson. We are not really good at communication. Stef > > The second example is too simple to be useful, but this would be the Zn equivalent: > > > (ZnServer defaultOn: 1337) > logToTranscript; > delegate: (ZnValueDelegate with: [ :request | > ZnResponse ok: (ZnEntity text: 'Hello World!') ]); > start. > > ZnClient get: 'http://localhost:1337'. > > (ZnServer defaultOn: 1337) > logToTranscript; > delegate: (ZnValueDelegate with: [ :request | > ZnResponse ok: (ZnEntity with: request contents) ]); > start. > > ZnClient post: 'http://localhost:1337' data: (ZnEntity text: 'Echo'). > > ZnServer stopDefault. > > > Smalltalk is a beautiful language, isn't it ? > > Sven > > PS: the delegate object has to respond to #handleRequest:. In earlier versions, it was a block, now ZnValueDelegate translates #handleRequest: to #value:. I thought that was clearer. For publicity reasons, maybe I could add a #delegateBlock: convencience accessor. > > > On 30 Jun 2011, at 17:07, StÃ©phane Ducasse wrote: > >> Hi guys >> >> apparently people get excited by nodeJS and I would like to know the equivalence of >> >> var http = require('http'); >> http.createServer(function (req, res) { >> res.writeHead(200, {'Content-Type': 'text/plain'}); >> res .end('Hello World\n'); >> }).listen(1337, "127.0.0.1"); >> >> console.log('Server running at http://127.0.0.1:1337/'); >> To run the server, put the code into a file example.js and execute it with the node program: >> >> % node example.js >> Server running at http://127.0.0.1:1337/ >> >> >> Here is an example of a simple TCP server which listens on port 1337 and echoes whatever you send it: >> >> var net = require('net'); >> var server = net.createServer(function (socket) { >> socket.write("Echo server\r\n"); >> socket.pipe(socket); >> }); >> >> server.listen(1337, "127.0.0.1"); >> >> >> we should communicate better :) >> >> Stef > >

June 30, 2011

Re: [Pharo-project] little challenge for sven and us

by Janko MivÅ¡ek

S, Sven Van Caekenberghe piÅ¡e: > > On 30 Jun 2011, at 17:53, Janko MivÅ¡ek wrote: > >> Because I'm just working on asynchronous no-blocking node.js like >> control flow in Aida, I can say that this is really natural to Smalltalk >> with its closures, much more than so called callbacks in JavaScript. In >> Smalltalk it is more readable and you hardly notice the difference to >> the normal Smalltalk code, while in JavaScript those callbacks are a bit >> hard to grasp and understand. From non seasoned programmer perspective, >> that is. > > Janko, that sounds promising, I would really love to learn more about your efforts. > > How do you do async IO without the select() system call ? As far as I know, that is not available as a VM primitive. Currently I'm introducing those techniques in Aida not for I/O but for tree-like control flow. One snippet from the forthcoming ToDo list example to confirm the delete of ToDo task (see attached screenshot): link := e addNilLinkText: 'Delete this task'. link onClickPopup: (WebDialog newConfirm text: 'Do you really want to delete that task?'; ifTrue: [self observee deleteTask: aToDoTask. aListElement update]). This is typical tree-like control flow scenario. When clicking on the link, a popup with Yes/No confirmation appear. If Yes is clicked, true is returned and ifTrue: block executed. Whole point is that this is a non-blocking code, in contrast to continuation based approach like in Seaside, where similar code would block and wait until dialog component returns answer. Here need to be mentioned that Iliad also use non-blocking tree-like control flow. Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

June 30, 2011

Re: [Pharo-project] little challenge for sven and us

by Igor Stasenko

2011/6/30 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > > > S, Norbert Hartl piÅ¡e: >> >> Am 30.06.2011 um 17:53 schrieb Janko MivÅ¡ek: >> >>> S, Norbert Hartl piÅ¡e: >>> >>>> Am 30.06.2011 um 17:23 schrieb StÃ©phane Ducasse: >>> >>>>>>> apparently people get excited by nodeJS and I would like to know the equivalence of >>> >>>>>> What does it mean? >>> >>>>> in Pharo.. how do you have the same: >>> >>>> It depends what is in your head when you wrote this. The code snippet doesn't tell that much. Registering a Block for execution on request is probably not what makes you excited about. What is exciting about it is that javascript is written in a strictly asynchronous manner (event driven) and that matches perfectly the implementation with asynchronous I/O. Suddenly you can write programs they way you ever wanted it. And lucky for us smalltalk itself is event driven so it can go there easily, too. Well, easily would mean to have support for asynchronous I/O in the vm (file operations) and in the socket plugin at least. >>> >>> Because I'm just working on asynchronous no-blocking node.js like >>> control flow in Aida, I can say that this is really natural to Smalltalk >>> with its closures, much more than so called callbacks in JavaScript. In >>> Smalltalk it is more readable and you hardly notice the difference to >>> the normal Smalltalk code, while in JavaScript those callbacks are a bit >>> hard to grasp and understand. From non seasoned programmer perspective, >>> that is. >>> >> Can you elaborate on this? I agree that one of the biggest flaws in javascript is that you have to write function() {} to use a closure which prevents its usage in a lot of cases, e.g. in filter functions etc. It is just ugly and nobody likes it. The second point is that you need to preserve this in javascript manually if you wish to use it in closures. >> Apart from that I can see a single difference between the two. Callbacks are natural to javascript because most usage pattern use it. Closures are natural to smalltalk because it just needs [ ] and it is well used throughout the class library. > > Let me show an example by Ryan Dahl, author of node.js. First in > JavaScript then how it will look in Smalltalk. > > Synchronous blocking database call: > > Â Â Â Â var result = db.query("select.."); > Â Â Â Â // wait > Â Â Â Â // use result > > Asynchronous non-blocking database call: > > Â Â Â Â db.query("select..", function (result) {// use result }); > Â Â Â Â // continue > > In first case program execution is blocked until database returns > result. In second case we register a callback function to deal with the > result. This function will be called later when result arrives, while we > don't wait but continue with execution. > > If you'll do in Smalltalk a blocking call: > > Â Â Â Â result := db query: 'select..'. > Â Â Â Â result useIt > > A non-blocking call can look something like: > > Â Â Â Â db query: 'select..' thenDo: [:result | result useIt ] > > As you see with our closures we can much more naturally and > understandably write such calls. > Indeed. Actually the recent JS popular libraries coding style reminds me more and more smalltalk. Looks like they are inventing new wheel, going long road from creepy C syntax and C programming style to smalltalk. > Best regards > Janko > -- Best regards, Igor Stasenko AKA sig.

June 30, 2011

Re: [Pharo-project] little challenge for sven and us

by Janko MivÅ¡ek

S, Norbert Hartl piÅ¡e: > > Am 30.06.2011 um 17:53 schrieb Janko MivÅ¡ek: > >> S, Norbert Hartl piÅ¡e: >> >>> Am 30.06.2011 um 17:23 schrieb StÃ©phane Ducasse: >> >>>>>> apparently people get excited by nodeJS and I would like to know the equivalence of >> >>>>> What does it mean? >> >>>> in Pharo.. how do you have the same: >> >>> It depends what is in your head when you wrote this. The code snippet doesn't tell that much. Registering a Block for execution on request is probably not what makes you excited about. What is exciting about it is that javascript is written in a strictly asynchronous manner (event driven) and that matches perfectly the implementation with asynchronous I/O. Suddenly you can write programs they way you ever wanted it. And lucky for us smalltalk itself is event driven so it can go there easily, too. Well, easily would mean to have support for asynchronous I/O in the vm (file operations) and in the socket plugin at least. >> >> Because I'm just working on asynchronous no-blocking node.js like >> control flow in Aida, I can say that this is really natural to Smalltalk >> with its closures, much more than so called callbacks in JavaScript. In >> Smalltalk it is more readable and you hardly notice the difference to >> the normal Smalltalk code, while in JavaScript those callbacks are a bit >> hard to grasp and understand. From non seasoned programmer perspective, >> that is. >> > Can you elaborate on this? I agree that one of the biggest flaws in javascript is that you have to write function() {} to use a closure which prevents its usage in a lot of cases, e.g. in filter functions etc. It is just ugly and nobody likes it. The second point is that you need to preserve this in javascript manually if you wish to use it in closures. > Apart from that I can see a single difference between the two. Callbacks are natural to javascript because most usage pattern use it. Closures are natural to smalltalk because it just needs [ ] and it is well used throughout the class library. Let me show an example by Ryan Dahl, author of node.js. First in JavaScript then how it will look in Smalltalk. Synchronous blocking database call: var result = db.query("select.."); // wait // use result Asynchronous non-blocking database call: db.query("select..", function (result) {// use result }); // continue In first case program execution is blocked until database returns result. In second case we register a callback function to deal with the result. This function will be called later when result arrives, while we don't wait but continue with execution. If you'll do in Smalltalk a blocking call: result := db query: 'select..'. result useIt A non-blocking call can look something like: db query: 'select..' thenDo: [:result | result useIt ] As you see with our closures we can much more naturally and understandably write such calls. Best regards Janko -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

June 30, 2011

Re: [Pharo-project] little challenge for sven and us

by Sven Van Caekenberghe

On 30 Jun 2011, at 18:01, Olivier Auverlot wrote: > I don't think that the buzz around NodeJS comes from these samples of code. Yes, it's very easy to starting a project with NodeJS but the interest from NodeJS is that this server extends the usages of Javascript wich becomes an language useable on many platform, many OS for many usages. With Javascript, programmers can write client code in browsers, widgets for desktop computers, shell scripts with Rhino, mobile applications for Android or IOS, ... and now, programmers can write server code for web applications and web services. Both what Olivier writes above and what Norbert writes (asynch support) are correct. Still, all this buzz around JS, Ruby, Python, Java, C#, whatever, is just that, buzz. Smalltalk has been an extremely dynamic binary cross platform language for decades, absorbing all kinds of new stuff. Yes, we can and should learn from other developments, but we should not be blinded by the hype. All these other platforms have their strengths, but many serious faults as well. So far, I haven't seen much that can't be done in Smalltalk in some way. And it is so much more easy, productive, nicer, pleasant, fun to do it in Smalltalk. Sven

June 30, 2011

Re: [Pharo-project] little challenge for sven and us

by Sven Van Caekenberghe

On 30 Jun 2011, at 17:53, Janko MivÅ¡ek wrote: > Because I'm just working on asynchronous no-blocking node.js like > control flow in Aida, I can say that this is really natural to Smalltalk > with its closures, much more than so called callbacks in JavaScript. In > Smalltalk it is more readable and you hardly notice the difference to > the normal Smalltalk code, while in JavaScript those callbacks are a bit > hard to grasp and understand. From non seasoned programmer perspective, > that is. Janko, that sounds promising, I would really love to learn more about your efforts. How do you do async IO without the select() system call ? As far as I know, that is not available as a VM primitive. Sven

June 30, 2011

Re: [Pharo-project] little challenge for sven and us

by Norbert Hartl

Am 30.06.2011 um 17:53 schrieb Janko MivÅ¡ek: > S, Norbert Hartl piÅ¡e: > >> Am 30.06.2011 um 17:23 schrieb StÃ©phane Ducasse: > >>>>> apparently people get excited by nodeJS and I would like to know the equivalence of > >>>> What does it mean? > >>> in Pharo.. how do you have the same: > >> It depends what is in your head when you wrote this. The code snippet doesn't tell that much. Registering a Block for execution on request is probably not what makes you excited about. What is exciting about it is that javascript is written in a strictly asynchronous manner (event driven) and that matches perfectly the implementation with asynchronous I/O. Suddenly you can write programs they way you ever wanted it. And lucky for us smalltalk itself is event driven so it can go there easily, too. Well, easily would mean to have support for asynchronous I/O in the vm (file operations) and in the socket plugin at least. > > Because I'm just working on asynchronous no-blocking node.js like > control flow in Aida, I can say that this is really natural to Smalltalk > with its closures, much more than so called callbacks in JavaScript. In > Smalltalk it is more readable and you hardly notice the difference to > the normal Smalltalk code, while in JavaScript those callbacks are a bit > hard to grasp and understand. From non seasoned programmer perspective, > that is. > Can you elaborate on this? I agree that one of the biggest flaws in javascript is that you have to write function() {} to use a closure which prevents its usage in a lot of cases, e.g. in filter functions etc. It is just ugly and nobody likes it. The second point is that you need to preserve this in javascript manually if you wish to use it in closures. Apart from that I can see a single difference between the two. Callbacks are natural to javascript because most usage pattern use it. Closures are natural to smalltalk because it just needs [ ] and it is well used throughout the class library. Norbert

June 30, 2011