November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] OSProcess - working on gnuplot

by David T. Lewis

On Tue, Nov 17, 2009 at 03:20:41PM -0500, Schwab,Wilhelm K wrote: > Stef, > > The only problems I have found are in the unit tests, which somewhere along the line cause a vm crash. Otherwise, it seems to work. Until it either proves unstable or otherwise lets me down, I'm trying to press forward with it, since I agree that it is REALLY important that this and other other FFI-like features work and work well. > > In general, I find the Linux vm to be too willing to crash w/o leaving a trace, or at least a trace that I know how to find(??). Hi Bill, I am not sure what was causing the crashes (I have seen this too, although not on the latest Pharo that I tried tonight). But I am quite sure that you should not blame the VM, and you should not blame Pharo either. In such a case, the fault lies with the person who wrote the plugin that crashed (that would be me). I expect that the unit tests ended up passing the "wrong" object as a parameter to some primitive in OSProcessPlugin, which in turn led to a crash. Most likely the symptoms (VM crash) will go away whenever we figure out the issues with OSProcess on Pharo, but only correct solution is to write the primitives with enough parameter checking that a VM crash cannot happen. If I see this problem again, I'll try running the VM under a gdb debugger to find out which primitive is causing the crash. That's probably the only way to find it, because the VM cannot prevent a sloppy plugin from doing a segfault and exiting. Dave

Nov. 18, 2009

Re: [Pharo-project] OSProcess - working on gnuplot

by David T. Lewis

On Tue, Nov 17, 2009 at 09:30:16AM +0100, Adrian Lienhard wrote: > Hi Dave, > > On Nov 17, 2009, at 01:40 , David T. Lewis wrote: > > [...] > > > If the above examples do not work for you, it is very likely due to > > the > > current inconsistencies between OSProcess and Pharo, for which I do > > not yet > > have a solution (I would welcome any tips here, I tried again last > > night to > > figure out what's wrong and gave up in frustration :-/ ). > > > What is the simplest thing to do to reproduce the problem? > > Do we know if it is on all platforms? Does it work in a Squeak Trunk > image? Hi Adrian, There are unit tests for OSProcess as well as for CommandShell, and these should all be green. Yes, all tests pass on Squeak trunk (see attached). I get inconsistent results on a Pharo image. I just tried again tonight on pharo1.0-10495-rc1dev09.11.3, and things look better than the last time I tried (which might be coincidental, I'm running various VMs and maybe I got myself confused the other evening). I'm not sure, but I think I am seeing two types of problem. The easy one is that I'm getting test failures in AioEventHandlerTestCase that are probably caused by changes in the socket code for Pharo compared to Squeak. I have not found the cause yet, but I'm not worried about it because it's probably just a change in the socket code for Pharo, and I probably will just need to adjust the tests for this. The harder problem is that I am getting intermittent failures, most often showing up in CommandShellTestCase (which does a lot of pipes, event handling, and OS process handling). I think that I am seeing failures in reading from pipes, which in turn results in failure to find end of file and clean up exiting processes. This causes the tests to get "stuck", and if I look in a terminal window, I can see that many of the processes spawned by the unit tests are in zombie mode, indicating that the grimReaperProcess running in Pharo/Squeak is failing to clean up processes that are ready to exit. I think that when I ran this on earlier Pharo images I was getting errors that had something to do with the fileID of a file stream (sorry I did not save the specific errors), so I am wondering if anything may have changed that would affect access to the fileID handle for a file stream. I have also seen VM crashes when running the tests, which suggests possibly passing the wrong kind of object to a primitive that expects a fileID byte array (and of course it also means that I need to do a better job of validating parameters passed to primitives in OSPP, but that's a separate topic ;) > Maybe I or other people can help to get more insights about what goes > wrong. OSProcess is certainly a very important package for Pharo, so > we should try to get it working again. Thanks for offering to help. I suspect that this will turn out to be one or two simple problems, and I just have not found them yet. Dave

Nov. 18, 2009

[Pharo-project] PhD position funded: Contribution to the design of domain specific languages for robotic applications

by Serge Stinckwich

LIP6, the Computer Science laboratory of the University of Paris 6, is offering a PhD studenship in software engineering for robotics. The student will take part in the PROTEUS (Platform for RObotic models Transformations and Exchange between Users and Scientific communities) project funded by ANR (french research agency) that will start on December 2009 with various partners in France. Candidates need to have a Master degree in computer science. Candidates for this position should have a strong software engineering background and be interested in robotics. Proficiency in written and spoken English is required. Knowledge of French is useful but not required. We will find a description of the PROTEUS project here: http://www.gdr-robotique.fr/archives_update/GT4/01_11_09/1256147659_PROTEUS… You should send your application (CV+ motivation letter) and any inquiry by email to Serge Stinckwich (Serge.Stinckwich(a)gmail.com) and Mikal Ziane (Mikal.Ziane(a)lip6.fr) Please find below a description of the Ph.D. subject in English and French. -------- Ph. D. Thesis title: "Contribution to the design of domain specific languages for robotic applications" Domain-specific languages (DSLs) are emerging as a key component of software engineering. A DSL is a modeling or programming language, dedicated to a particular problem domain, through appropriate notations and abstractions. They are often designed to express the requirements and solutions of a particular domain and has many benefits for developing software. The main purpose of Domain-Specific Modeling languages (DSMLs) is to allow for domain users (that are not programmers usually) to think in terms closer to the problem domain when specifying their systems, by providing a way to model them at the right abstraction level. DSL are already used in the context of embedded systems and the interests for the robotic community is also huge. Robotics system blends software/hardware in a very intrinsic way with a lot of cross-cutting concerns (concurrency, uncertainty, time constraints, ...). Adapting general purpose languages for such a domain often leads to a poor ï¬t between the language features and the implementation requirements. The main aim of PROTEUS project is the design and the implementation of a software development environment for robotics applications. This environment should provide several domain specific languages (DSL) in order to specify the software architecture and the behavior of a robotic system. This language will allow to specify robotic applications without having to specify low-level details including the details regarding the execution platform. This environment through carefully defined transformations will translate this language into an intermediate language. ------- Titre de la thÃ¨se : "Contribution Ã la conception de langages de domaine (Domain Specific Language) pour la robotique" Les langages de domaines (DSL) sont maintenant considÃ©rÃ©s comme une approche importante dans les bonnes pratiques de gÃ©nie logiciel. Un langage de domaine est un langage de programmation ou de modÃ©lisation, dÃ©diÃ© Ã un domaine spÃ©cifique et qui utilisent pour cela des notations ou d'abstractions adaptÃ©es. Ils sont souvent conÃ§us pour exprimer les besoins et les solutions d'un domaine spÃ©cifique et offrent de nombreux bÃ©nÃ©fices pour le dÃ©veloppement de logiciel. Le principal intÃ©rÃªt des DSLs est qu'ils permettent Ã des utilisateurs d'un domaine (qui ne sont gÃ©nÃ©ralement pas des dÃ©veloppeurs) de pouvoir penser en terme proche de leur domaine lorsqu'ils spÃ©cifient leurs systÃ¨mes. Les DSLs sont dÃ©jÃ utilisÃ©s dans le contexte des systÃ¨mes embarquÃ©s et leurs apports dans la communautÃ© robotique semblent Ã©galement prometteurs. Les systÃ¨mes robotiques mÃ¨lent Ã la fois des aspects matÃ©riels et logiciels avec de nombreuses prÃ©occupations spÃ©cifiques (concurrence, incertitude, contraintes temporelles, ...). Adapter des langages classiques Ã un tel domaine ne suffit pas et conduit gÃ©nÃ©ralement Ã une mauvaise adÃ©quation entre les caractÃ©ristiques du langage et les besoins du domaine. Le principal objectif du projet PROTEUS (Plate forme pour la Robotique Organisant les Transferts Entre Utilisateurs et Scientifiques) est la conception et l'implÃ©mentation d'un environnement de dÃ©veloppement pour la rÃ©alisation d'applications robotiques. Cet environnement comprendra un ou plusieurs langage de domaine (domain-specific language, DSL) permettant de spÃ©cifier lâaspect architectural dâune application robotique mais aussi son aspect comportemental dÃ©crivant la partie contrÃ´le et communication. Ce langage devra permettre de spÃ©cifier une application robotique sans avoir Ã prÃ©ciser les dÃ©tails de bas niveau et notamment les dÃ©tails qui dÃ©pendent de la plateforme dâexÃ©cution. Lâenvironnement, grÃ¢ce Ã des transformations soigneusement dÃ©finies, traduira les programmes de ce langage vers un langage intermÃ©diaire indÃ©pendant de la plateforme. -------- Best regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Nov. 18, 2009

Re: [Pharo-project] Connectors

by Andrew P. Black

Is there any documentation? Andrew On 17 Nov 2009, at 03:46, Alexandre Bergel wrote: > I recommand you to give a try at Mondrian. > http://www.squeaksource.com/Mondrian.html

Nov. 17, 2009

Re: [Pharo-project] Socket accepts ipv6 addresses, but can not connect to them

by Adrian Lienhard

I don't know the details about the "old" and "new" network implementation (IPv4 vs. IPv6?), but if the old works and the new does not we should definitely change the default back to the old one. Adrian On Nov 17, 2009, at 22:13 , StÃ©phane Ducasse wrote: > No this is a good point. > Adrian we should really useOldNetwork in the final version > > Stef > > On Nov 17, 2009, at 8:51 PM, Bart Gauquie wrote: > >> Hi, >> >> If i modify the #useOldNetwork method, everything works. Thanks for >> that tip. >> >> However: is this not a 'bug' in Pharo to have ipv6 as default, >> since it is not working properly? With my simple SocketTest not >> working for instance? >> >> Kind regards, >> >> Bart >> >> >> 2009/11/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> FWIW, I am fairly certain the IPv6 changes are incomplete at best. >> Others have reported needing to override #useOldNetwork to always >> answer true, and I have noted things that are called "in the clear" >> when they should be hidden behind an old net test. >> >> So far, I have done what amounts to some glorified loopback tests >> and have watched MC download packages from IPv4 addresses. >> >> Bill >> >> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of Bart Gauquie >> Sent: Monday, November 16, 2009 4:26 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Socket accepts ipv6 addresses, but can not >> connect to them >> >> Dear all, >> >> I'm using Pharo1.0rc1 Latest update: #10493, on Windows Vista , >> runtime 3.11.4. >> >> Following test is going fine: >> SocketTest >> >>testConnectToLocalhostThroughNetNameResolverAddressForNameLocalhost >> |serverSocket clientSocket address| >> >> serverSocket := Socket newTCP. >> clientSocket := Socket newTCP. >> >> [ serverSocket listenOn: 6665. >> address := NetNameResolver addressForName: '127.0.0.1' timeout: 20. >> clientSocket connectTo: address port: 6665] >> ensure: [ >> clientSocket close. >> serverSocket close. >> ] >> >> (connect to a socket on localhost) >> >> however, following test: >> >> testConnectToLocalhostThroughNetNameResolverLocalHostAddress >> |serverSocket clientSocket address| >> >> serverSocket := Socket newTCP. >> clientSocket := Socket newTCP. >> >> [ serverSocket listenOn: 6665. >> address := NetNameResolver localHostAddress. >> clientSocket connectTo: address port: 6665] >> ensure: [ >> clientSocket close. >> serverSocket close. >> ] >> >> is failing with following error: >> ConnectionTimedOut: Cannot connect to: >> fe80::6dd3:7860:93c9:46a0%10(PC_xxx),6665(6665) >> >> [] in Socket>>connectTo:waitForConnectionFor: >> Socket>>waitForConnectionFor:ifTimedOut: >> Socket>>connectTo:waitForConnectionFor: >> Socket>>connectTo: >> Socket>>connectTo:port: >> [] in >> SocketTest >> >>testConnectToLocalhostThroughNetNameResolverLocalHostAddress >> BlockClosure>>ensure: >> SocketTest >> >>testConnectToLocalhostThroughNetNameResolverLocalHostAddress >> SocketTest(TestCase)>>performTest >> [] in [] in SocketTest(TestCase)>>runCase >> BlockClosure>>ensure: >> >> I understand that the above address is an ipv6 address. (the >> NetNameResolver localHostAddress lookup returns on my machine a >> ipv6 address) >> If i do ipconfig on my machine: >> >> Ethernet-adapter LAN-verbinding: >> >> Verbindingsspec. DNS-achtervoegsel: lan >> Link-local IPv6-adres . . . . . . : fe80::6dd3:7860:93c9:46a0%10 >> IPv4-adres. . . . . . . . . . . . : 10.0.0.39 >> Subnetmasker. . . . . . . . . . . : 255.255.255.0 >> Standaardgateway. . . . . . . . . : 10.0.0.138 >> >> its the same ipv6 address. >> >> Is it normal that the Socket class can not handle ipv6 addresses ? >> I get a timeoutexception on it (however this happens immediately). >> >> Is this the behaviour that i can expect ? >> The reason i noticed this is that I'm trying Magma, the server in a >> separate image but on the same machine, under ubuntu 9.10 >> everything worked fine, under Windows Vista it crashed, since >> internally it also uses NetNameResolver localHostAddress to connect >> to 'localhost', and i got the same connect timeout exception. >> >> In attachment, a fileout of the SocketTest (had to create a new >> testclass for this :-( ) >> >> Kind regards, >> >> Bart >> >> -- >> imagination is more important than knowledge - Albert Einstein >> Logic will get you from A to B. Imagination will take you >> everywhere - Albert Einstein >> Learn from yesterday, live for today, hope for tomorrow. The >> important thing is not to stop questioning. - Albert Einstein >> The true sign of intelligence is not knowledge but imagination. - >> Albert Einstein >> Gravitation is not responsible for people falling in love. - Albert >> Einstein >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 17, 2009

Re: [Pharo-project] Connectors

by Bryce Kampjes

On Tue, 2009-11-17 at 20:14 +0100, Lukas Renggli wrote: > >> http://www.svgopen.org/2009/papers/58-Interactive_Documentation_using_JavaS… > > > > What you have in Figure 3 is fairly trivial to obtain. I can provide > > scripts for this. > > Other figure are doable, but may require effort. I can help on this. > > I know how to do the tree, but that's not that interesting. I am more > interested into Figure 13 > (http://www.svgopen.org/2009/papers/58-Interactive_Documentation_using_JavaS…) > and 14. > > In Morphic (with the exception of the arrows) this is easy to do when > nesting some containers into each other. I first thought that this > would be something for Mondrian, but it seems to be very hard at the > moment. Maybe this is also out of the scope of Mondrian? I do something similar to that for Exupery's graphical method inspectors. I've used first Connectors and now Mondrian. I do the layout with graphvis and tweak it by hand if necessary. Mondrian is at least as easy to use for this as Connectors. If you're interested in the code, its the classes MOGraphVizLayout and ExuperyMondrianMethodInspector in Exupery. Bryce

Nov. 17, 2009

Re: [Pharo-project] Socket accepts ipv6 addresses, but can not connect to them

by Henrik Sperre Johansen

Not that I have any experience in the area, but would it be an idea to rename it to useIPv4 as well? I don't know about others, but the name of that method annoys me _every_ time I see this problem mentioned... Cheers, Henry On 17.11.2009 22:13, StÃ©phane Ducasse wrote: > No this is a good point. > Adrian we should really useOldNetwork in the final version > > Stef > > On Nov 17, 2009, at 8:51 PM, Bart Gauquie wrote: > > >> Hi, >> >> If i modify the #useOldNetwork method, everything works. Thanks for that tip. >> >> However: is this not a 'bug' in Pharo to have ipv6 as default, since it is not working properly? With my simple SocketTest not working for instance? >> >> Kind regards, >> >> Bart >> >> >> 2009/11/16 Schwab,Wilhelm K<bschwab(a)anest.ufl.edu> >> FWIW, I am fairly certain the IPv6 changes are incomplete at best. Others have reported needing to override #useOldNetwork to always answer true, and I have noted things that are called "in the clear" when they should be hidden behind an old net test. >> >> So far, I have done what amounts to some glorified loopback tests and have watched MC download packages from IPv4 addresses. >> >> Bill >> >> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Bart Gauquie >> Sent: Monday, November 16, 2009 4:26 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Socket accepts ipv6 addresses, but can not connect to them >> >> Dear all, >> >> I'm using Pharo1.0rc1 Latest update: #10493, on Windows Vista , runtime 3.11.4. >> >> Following test is going fine: >> SocketTest>>testConnectToLocalhostThroughNetNameResolverAddressForNameLocalhost >> |serverSocket clientSocket address| >> >> serverSocket := Socket newTCP. >> clientSocket := Socket newTCP. >> >> [ serverSocket listenOn: 6665. >> address := NetNameResolver addressForName: '127.0.0.1' timeout: 20. >> clientSocket connectTo: address port: 6665] >> ensure: [ >> clientSocket close. >> serverSocket close. >> ] >> >> (connect to a socket on localhost) >> >> however, following test: >> >> testConnectToLocalhostThroughNetNameResolverLocalHostAddress >> |serverSocket clientSocket address| >> >> serverSocket := Socket newTCP. >> clientSocket := Socket newTCP. >> >> [ serverSocket listenOn: 6665. >> address := NetNameResolver localHostAddress. >> clientSocket connectTo: address port: 6665] >> ensure: [ >> clientSocket close. >> serverSocket close. >> ] >> >> is failing with following error: >> ConnectionTimedOut: Cannot connect to: fe80::6dd3:7860:93c9:46a0%10(PC_xxx),6665(6665) >> >> [] in Socket>>connectTo:waitForConnectionFor: >> Socket>>waitForConnectionFor:ifTimedOut: >> Socket>>connectTo:waitForConnectionFor: >> Socket>>connectTo: >> Socket>>connectTo:port: >> [] in SocketTest>>testConnectToLocalhostThroughNetNameResolverLocalHostAddress >> BlockClosure>>ensure: >> SocketTest>>testConnectToLocalhostThroughNetNameResolverLocalHostAddress >> SocketTest(TestCase)>>performTest >> [] in [] in SocketTest(TestCase)>>runCase >> BlockClosure>>ensure: >> >> I understand that the above address is an ipv6 address. (the NetNameResolver localHostAddress lookup returns on my machine a ipv6 address) >> If i do ipconfig on my machine: >> >> Ethernet-adapter LAN-verbinding: >> >> Verbindingsspec. DNS-achtervoegsel: lan >> Link-local IPv6-adres . . . . . . : fe80::6dd3:7860:93c9:46a0%10 >> IPv4-adres. . . . . . . . . . . . : 10.0.0.39 >> Subnetmasker. . . . . . . . . . . : 255.255.255.0 >> Standaardgateway. . . . . . . . . : 10.0.0.138 >> >> its the same ipv6 address. >> >> Is it normal that the Socket class can not handle ipv6 addresses ? I get a timeoutexception on it (however this happens immediately). >> >> Is this the behaviour that i can expect ? >> The reason i noticed this is that I'm trying Magma, the server in a separate image but on the same machine, under ubuntu 9.10 everything worked fine, under Windows Vista it crashed, since internally it also uses NetNameResolver localHostAddress to connect to 'localhost', and i got the same connect timeout exception. >> >> In attachment, a fileout of the SocketTest (had to create a new testclass for this :-( ) >> >> Kind regards, >> >> Bart >> >> -- >> imagination is more important than knowledge - Albert Einstein >> Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein >> Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein >> The true sign of intelligence is not knowledge but imagination. - Albert Einstein >> Gravitation is not responsible for people falling in love. - Albert Einstein >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Nov. 17, 2009

Re: [Pharo-project] Socket accepts ipv6 addresses, but can not connect to them

by StÃ©phane Ducasse

No this is a good point. Adrian we should really useOldNetwork in the final version Stef On Nov 17, 2009, at 8:51 PM, Bart Gauquie wrote: > Hi, > > If i modify the #useOldNetwork method, everything works. Thanks for that tip. > > However: is this not a 'bug' in Pharo to have ipv6 as default, since it is not working properly? With my simple SocketTest not working for instance? > > Kind regards, > > Bart > > > 2009/11/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > FWIW, I am fairly certain the IPv6 changes are incomplete at best. Others have reported needing to override #useOldNetwork to always answer true, and I have noted things that are called "in the clear" when they should be hidden behind an old net test. > > So far, I have done what amounts to some glorified loopback tests and have watched MC download packages from IPv4 addresses. > > Bill > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Bart Gauquie > Sent: Monday, November 16, 2009 4:26 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Socket accepts ipv6 addresses, but can not connect to them > > Dear all, > > I'm using Pharo1.0rc1 Latest update: #10493, on Windows Vista , runtime 3.11.4. > > Following test is going fine: > SocketTest>>testConnectToLocalhostThroughNetNameResolverAddressForNameLocalhost > |serverSocket clientSocket address| > > serverSocket := Socket newTCP. > clientSocket := Socket newTCP. > > [ serverSocket listenOn: 6665. > address := NetNameResolver addressForName: '127.0.0.1' timeout: 20. > clientSocket connectTo: address port: 6665] > ensure: [ > clientSocket close. > serverSocket close. > ] > > (connect to a socket on localhost) > > however, following test: > > testConnectToLocalhostThroughNetNameResolverLocalHostAddress > |serverSocket clientSocket address| > > serverSocket := Socket newTCP. > clientSocket := Socket newTCP. > > [ serverSocket listenOn: 6665. > address := NetNameResolver localHostAddress. > clientSocket connectTo: address port: 6665] > ensure: [ > clientSocket close. > serverSocket close. > ] > > is failing with following error: > ConnectionTimedOut: Cannot connect to: fe80::6dd3:7860:93c9:46a0%10(PC_xxx),6665(6665) > > [] in Socket>>connectTo:waitForConnectionFor: > Socket>>waitForConnectionFor:ifTimedOut: > Socket>>connectTo:waitForConnectionFor: > Socket>>connectTo: > Socket>>connectTo:port: > [] in SocketTest>>testConnectToLocalhostThroughNetNameResolverLocalHostAddress > BlockClosure>>ensure: > SocketTest>>testConnectToLocalhostThroughNetNameResolverLocalHostAddress > SocketTest(TestCase)>>performTest > [] in [] in SocketTest(TestCase)>>runCase > BlockClosure>>ensure: > > I understand that the above address is an ipv6 address. (the NetNameResolver localHostAddress lookup returns on my machine a ipv6 address) > If i do ipconfig on my machine: > > Ethernet-adapter LAN-verbinding: > > Verbindingsspec. DNS-achtervoegsel: lan > Link-local IPv6-adres . . . . . . : fe80::6dd3:7860:93c9:46a0%10 > IPv4-adres. . . . . . . . . . . . : 10.0.0.39 > Subnetmasker. . . . . . . . . . . : 255.255.255.0 > Standaardgateway. . . . . . . . . : 10.0.0.138 > > its the same ipv6 address. > > Is it normal that the Socket class can not handle ipv6 addresses ? I get a timeoutexception on it (however this happens immediately). > > Is this the behaviour that i can expect ? > The reason i noticed this is that I'm trying Magma, the server in a separate image but on the same machine, under ubuntu 9.10 everything worked fine, under Windows Vista it crashed, since internally it also uses NetNameResolver localHostAddress to connect to 'localhost', and i got the same connect timeout exception. > > In attachment, a fileout of the SocketTest (had to create a new testclass for this :-( ) > > Kind regards, > > Bart > > -- > imagination is more important than knowledge - Albert Einstein > Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein > Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein > The true sign of intelligence is not knowledge but imagination. - Albert Einstein > Gravitation is not responsible for people falling in love. - Albert Einstein > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 17, 2009

Re: [Pharo-project] SystemVersion 1.0 and 1.1

by Michael Roberts

no problem ;-) Mike On Tue, Nov 17, 2009 at 7:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > time :) > > Stef > > On Nov 17, 2009, at 7:15 PM, Michael Roberts wrote: > >> Stef/Adrian/Marcus Â what more do you need to integrate this please? >> did I miss something? >> >> Thanks >> mike >> >> On Sunday, November 15, 2009, Michael Roberts <mike(a)mjr104.co.uk> wrote: >>> Please review these changes for 1.0 & 1.1 branches. Â This currently >>> only bootstraps better version strings. Â After this I have some class >>> changes and deprecations for 1.1 (only). >>> >>> =1.0 branch= >>> http://code.google.com/p/pharo/issues/detail?id=1446 >>> >>> In the inbox is a template update: >>> >>> Name: ScriptLoader-MikeRoberts.1134 >>> Author: MikeRoberts >>> Ancestors: ScriptLoader-AdrianLienhard.1133 >>> >>> =1.1 branch= >>> http://code.google.com/p/pharo/issues/detail?id=1447 >>> >>> In the inbox is a template update: >>> >>> Name: ScriptLoader11-MikeRoberts.54 >>> Author: MikeRoberts >>> Ancestors: ScriptLoader11-StephaneDucasse.53 >>> >>> >>> === >>> This just sets the system version in both branches. Note that the two >>> update lists must be updated immediately afterwards. >>> >>> This has the ability to break the update stream so please review carefully! >>> >>> thanks, >>> Mike >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 17, 2009

Re: [Pharo-project] Pharo 1.0 RC1 feedback.

by Michael van der Gulik

On Wed, Nov 18, 2009 at 2:03 AM, Marcus Denker <denker(a)acm.org> wrote: > > On Nov 17, 2009, at 8:49 AM, Michael van der Gulik wrote: > > > Hi. > > > > Here's some feedback for Pharo. I've been using Squeak 3.10, but because > I want to use the NewCompiler, I'm going to move development of SecureSqueak > to Pharo. > > > > I go to http://pharo.org/. Woops. He he. I find my way to the Pharo home > page. > > > > Getting Pharo up and running could be a lot easier; I'm using Ubuntu > Linux, and I got it up and running quickly because I've a fairly experienced > Squeak developer. If I was less familiar with image files and VMs, I would > be lost and probably give up. > > > > I recommend making the release for each platform one large .zip file > containing the images, sources and VM. This will reduce confusion, and if > you put the executable in the root directory of the zip file, most people > will easily be able to work it out. > > > > The idea was to move to single-click images for beginners. See > > > http://gforge.inria.fr/frs/download.php/23260/Pharo1.0-10440-BETAdev09.09ON… > > for an example. > > For the rest, yes... sadly there are only 24h in the day.... > > Please add bug reports for all suggestions: > > http://code.google.com/p/pharo/issues/ > > Okay. I'll fill out bug reports for what I consider to be real issues. I think that presentation should have a high priority. You want your "product" to appeal to new users well out of the box. It's difficult to tell how many people download Pharo, try it, can't get it working or get it working and can't understand it, and then discard it. Gulik. -- http://gulik.pbwiki.com/

Nov. 17, 2009