- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Silly Tweet

by Norbert Hartl

Am 30.06.2011 um 10:32 schrieb Stephan Eggermont: > Stef wrote in response to my: >>> Ok, so you simply do not want the builds to be used by others. >>> That's fine. > >> why do you say that? > > Such a build server can have two purposes: > - to directly help with the development of the software named in the build jobs; > - it can provide a starting point for others to base their work on. > > Both are valuable, and it is acceptable if you want to want to focus on the first. > For the second, as a commercial developer I have to be able to make my upgrade > schedule as independent as possible from that of the projects I depend on. > Depending on artifacts with an unknown availability is not possible. > Exactly. And that is the reason why it will be very hard not to have your own CI server. The official distribution will rarely match your requirements. We all patch packages here and there. That you can only deal with in your own setting. All CI servers that I know (most of big development teams) face sooner or later the same thing. You might think disk space is endless or CPU but it is not. I don't know any bigger CI server that still builds all commits. It is just not possible because CPU and disk space isn't there enough. From that angle it is even more important to remove the things that aren't really needed. I think you are actually looking for a reliable download location and the CI server is the wrong place for it. That's why there are last successful builds. The can be copied to a download server and rest forever. my 2 cents, Norbert >> What is the point to have a build server build all the time the same same same same same >> same same image? > > A build server is used as we've learned there is no such thing as the same same image. > There have been regressions because of vm changes or operating system updates, > and I've seen 1.2.1 and 1.2.2. Also, while Pharo might be the same, both Zinc and Seaside > change. > > Stephan > > > >

June 30, 2011