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

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

by Olivier Auverlot

Hi Stef, 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. My two cents Olivier ;-) www.auverlot.fr > 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, 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. 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 Norbert Hartl

Am 30.06.2011 um 17:23 schrieb StÃ©phane Ducasse: >>> Hi guys >>> >>> 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. Is that what you asked? Norbert > >>> 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 Sven Van Caekenberghe

StÃ©phane, That's not really a challenge ;-) 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] Silly Tweet

by StÃ©phane Ducasse

Now what is a set up that can help you? We could keep 1.0, 1.2, images around without building them systematically. and their dependent projects could still be updated and run from the server. Stef

June 30, 2011

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

by StÃ©phane Ducasse

>> Hi guys >> >> 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: >> 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 Norbert Hartl

Am 30.06.2011 um 17:07 schrieb StÃ©phane Ducasse: > Hi guys > > apparently people get excited by nodeJS and I would like to know the equivalence of > What does it mean? Norbert > 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

[Pharo-project] little challenge for sven and us

by StÃ©phane Ducasse

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] Silly Tweet

by Dave Mason

It has been suggested that package maintainers should run their own CI server to track changes of their package on older images. That seems eminently reasonable. What would be hugely helpful for that would be a script or tar-file downloadable from the Pharo CI server for each image version (historical and current) that one (such as me) could download and get running with minimal information about the arcane knowledge required for configuring Hudson/Jenkins. Then I could easily track my package's compatibility with legacy images and decide when I am willing to break with e.g. 1.1 compatibility for my package. I know this would take a chunk of time for somebody, but I suggest it would be time well spent because it lets the main CI server concentrate on the current version, but supports package maintainers moving forward with their packages. ../Dave

June 30, 2011

Re: [Pharo-project] Silly Tweet

by Adrian Lienhard

On Jun 30, 2011, at 10:15 , Marcus Denker wrote: > On Jun 30, 2011, at 9:57 AM, Fernando Olivero wrote: > >> Why do people still use an older image? Even as older as Pharo1.1 and 1.2. >> >> It doesn't take much to update to Pharo1.3 or Pharo1.4, and its >> totally worth the nuisance of updating a couple of classes references >> and uses, because of the many many many improvements that get >> integrated ( thanks for Marcus and Stef for the continuos improvements >> integration and fixes) > > In a commercial setting, things are different... people need to really think hard > to move to a new system. Time is money, bugs are expensive, there is always > a deadline more important... Exactly. When you have systems of the size >1000 classes that have been grown over years and have to work reliably, just "updating a couple of classes [sic] references and uses" is not easy. First of all, you have to figure out *what* to change. Changes like a modified Dictionary/Set hierarchy can subtly break your code (leading to data corruption in our case [1]). Or, just because you are one of the first to use the new code under high load, you see problems others haven't seen before (leading to unresponsive images in our case [2]). Those are obvious external bugs, but we also ran into issues with our code just not being compatible anymore with new semantics (e.g., Number class>>#readFrom:). That's why in a non-trivial setup, upgrading is costly, and at times painful (in particular when you missed problems in testing and then experience them in production). [1] http://code.google.com/p/pharo/issues/detail?id=3658 [2] http://code.google.com/p/pharo/issues/detail?id=3498 Cheers, Adrian

June 30, 2011