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

Re: [Pharo-project] Pharo name format

by Mariano Martinez Peck

On Sat, Aug 1, 2009 at 6:24 PM, Marcus Denker <denker(a)acm.org> wrote: > > On 01.08.2009, at 16:32, Michael Roberts wrote: > > > my preference would be everything you describe apart from the tag. I > > am not a fan of encoding too much in the file name. I would prefer > > some decent release notes contained within the zip. > > > > Yes, we need to be better in changelog management. We need: > > -> A Blog on the pharo CMS for posting all the things there > in addition to the [update] posts (beeing worked on, should > be ready next week) > -> A ChangeLog.txt with every zip. > -> A changelog available on the downloads page. > I am agree with all Miguel suggestions. Even with tags because they are optional. You can put tags when necessary, not always. On the other hand, I am agree to have a ChangeLog.txt with every zip and also to be able to see changelog from website. > > > Marcus > > > > thanks, > > mike > > > > 2009/8/1 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: > >> Now that the release date for pharo is close, I propose to use the > >> following sintax for the pharo core products > >> > >> PharoCore-x.y-#####-TagName.zip > >> > >> where > >> x.y > >> is the version of pharo (0.1, 1.0, 1.1, 2.0, 2.1, etc) > >> ##### > >> is the number of image release in that version (10449, 10450, 10451, > >> etc) > >> TagName > >> is a tag for better explain some specific feature of the image > >> (closure, RELEASE, STABLE, beta, etc) > >> > >> e.g. > >> > >> For a normal daily release, say 10450, in the 0.1 branch: > >> > >> PharoCore-0.1-10450.zip > >> > >> For the image that has all tests in green: > >> > >> PharoCore-0.1-10456-AllTestGreen.zip > >> > >> For the image that it is the first stable 1.0: > >> > >> PharoCore-1.0-10478-RELEASE_1_0.zip > >> > >> For the next image with the NewCompiler code integrated, after the > >> 1.0 > >> release: > >> > >> PharoCore-1.0-10490-NewCompiler.zip > >> > >> For a subsecuent 1.1 release, that includes NewCompiler: > >> > >> PharoCore-1.1-10511-RELEASE_1_1.zip > >> > >> When, for example, 1.1 is the current branch, and 1.0 has fixes > >> support > >> and a new emergency release for the old 1.0 branch: > >> > >> PharoCore-1.0-10512-UPDATE_1.zip > >> > >> Release for pharo 2.0: > >> > >> PharoCore-2.0-10890-RELEASE_2_0.zip > >> > >> Other fix in the 1.1 branch (brach 1.0 is out of support): > >> > >> PharoCore-1.1-10915-UPDATE_1.zip > >> > >> Notes: We can also reset the number in each mayor release (0.1, 1.0, > >> 1.1, etc) so that the updates to the old supportes branches can be a > >> continuous. For example, the previous names would be (in the same > >> order > >> of release as the examples above): > >> > >> PharoCore-0.1-10450.zip > >> > >> PharoCore-0.1-10456-AllTestGreen.zip > >> > >> PharoCore-1.0-10001-RELEASE_1_0.zip > >> > >> PharoCore-1.0-10002-NewCompiler.zip > >> > >> PharoCore-1.1-10001-RELEASE_1_1.zip > >> > >> PharoCore-1.0-10003-UPDATE_1.zip > >> > >> PharoCore-2.0-10001-RELEASE_2_0.zip > >> > >> PharoCore-1.1-10002-UPDATE_1.zip > >> > >> etc > >> > >> Also, the PharoCore-1.0-10001-RELEASE_1_0.zip would be a copy of the > >> last image of 0.1 branch (in this example > >> PharoCore-0.1-10456-AllTestGreen.zip) > >> > >> But this is mostly estetic and can potentially confuse new users. > >> > >> What do you think? > >> > >> > >> _______________________________________________ > >> 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 >

Aug. 2, 2009

[Pharo-project] Debbuging problems, FFI

by Mariano Martinez Peck

Hi folks, In Pharo mailing list, there are people trying to fix the known bug when debugging with FFI. The bug report is this: http://bugs.squeak.org/view.php?id=6436 Javier has done an excellent job and here is his last post. Can someone read what he found and see if we can fix this annoying bug? Thanks, Mariano ---------- Forwarded message ---------- From: Javier PimÃ¡s <elpochodelagente(a)gmail.com> Date: 2009/8/2 Subject: Re: [Pharo-project] Debbuging problems, FFI To: Pharo-project(a)lists.gforge.inria.fr I Think I found where the problem lies, it's just sitting there waiting to be resolved. To see what was happening I debugged the debuger, which was really weird. I found the answer when I broke into the step over button by adding a self break in OTCmdOverDebugger>>execute. After catching it I removed the break and stepped into everything to see how step over worked. The intresting part is in MethodContext(ContextPart)>>step, which sends interpretNextInstructionFor: self. The idea is this, instead of advancing the vm program counter within the vm code, the debugger simulates the execution cycle, step by step. It not so hard as it seems but also not very simple. The problem comes when the debugger tryies to simulate primitive calls. When the simulator detects a primitive, it issues a MethodContext(ContextPart)>>doPrimitive:method:receiver:args:, here you can see the detection: tryPrimitiveFor: method receiver: receiver args: arguments "..." | primIndex | (primIndex := method primitive) = 0 ifTrue: [^ PrimitiveFailToken]. ^ self doPrimitive: primIndex method: method receiver: receiver args: arguments well, the problem is that doPrimitive doesn't seem to implement all primitives (I recomend you to look it's code), but just a few ones. Also, as far as I can see, it calls primitive 19, which i found is (by looking vm C code) primitiveFail, and that primitive just sets a flag that says that something failed. Then, if my calculations are correct, the problem is that the FFI Call primitive needs to be handled by hand. I tryied adding this to ContextPart>>doPrimitive:method:receiver:args: primitiveIndex = 120 ifTrue: "Calling an FFI method, just evaluate it and return" [ meth valueWithReceiver: receiver arguments: arguments . ^self]. just before arguments size > 6 ifTrue: [^PrimitiveFailToken]. which I think almost worked. I think the primitive was executed, but this doesn't handle the execution context that is being simulated, and the stack gets corrupted. Somebody with more experience in ContextPart, MethodContext, etc. may give us a hand here, I think the fix is almost there. Bye, Javier. 2009/7/31 Mariano Martinez Peck <marianopeck(a)gmail.com> > > 2009/7/31 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > >> Does anybody know if the problem occurs just in Windows or in any OS? this >> can give a clue of the problem... >> >> > I don't remember debugging in Windows, but in Linux I have this problem for > sure. > > >> >> On Thu, Jul 30, 2009 at 11:28 PM, Javier PimÃ¡s < >> elpochodelagente(a)gmail.com> wrote: >> >>> Well, at least I feel better that I'm not crazy, (or not the only >>> one...). Maybe if someone could give us a clue about it, we could spot where >>> the problem is. Do you think it is a vm problem or something related to the >>> smalltalk code? >>> >>> 2009/7/30 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>> Yes. This is really annoying for me. I am writing a C library plugin >>>> since a year and a half and this is very frustrated :( >>>> You cannot debug when using FFI. I mean, you cannot get advantages of >>>> one of the best Smalltalk features! What I do is to write a self break >>>> before and after the call and use "proceed" but I don't like it at all. >>>> >>>> Once I tried to see what the problem was, but I was to difficult to me >>>> to understand it and fix it. We need a guru here I think hahaha. >>>> >>>> Best, >>>> >>>> Mariano >>>> >>>> 2009/7/30 Javier PimÃ¡s <elpochodelagente(a)gmail.com> >>>> >>>>> Hi, I'm having problems with the debugger. Every time I try to debug >>>>> code that uses FFI, if I step over a message that internally does an FFI >>>>> call, I get an externalCallFailed error and then I land in >>>>> MethodContext(ContextPart)>>runUntilErrorOrReturnFrom: >>>>> If I run the code without debugging, then I have no problems at all. >>>>> >>>>> I'm using SqueakPharo v3.11.2 with pharo0.1-10373web09.07.2. >>>>> >>>>> To reproduce it you can try this: >>>>> >>>>> ScriptLoader loadFFI. >>>>> then load latest GLMorphic from squeaksource, and uncomment the "self >>>>> break." in >>>>> GLCanvas>>displayString:from:to:at:strikeFont:kern: >>>>> >>>>> doit >>>>> World fullDrawOn: GLDisplayScreen testCanvas >>>>> hit debug and step over until you reach >>>>> ogl glTexImage2D: GLTexture2d with:... >>>>> >>>>> also you'll see wrong values for local vars, like aPoint which will >>>>> look as #(nil nil nil nil nil) when it'll actually have a point. >>>>> >>>>> Is there any other way to set up a break point instead of adding self >>>>> break to the code?? >>>>> >>>>> Thanks, >>>>> Javier. >>>>> >>>>> -- >>>>> Javier PimÃ¡s >>>>> Ciudad de Buenos Aires >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Javier PimÃ¡s >>> Ciudad de Buenos Aires >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> _______________________________________________ >> 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 > -- Javier PimÃ¡s Ciudad de Buenos Aires _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 2, 2009

Re: [Pharo-project] table widget

by Carlos Crosetti

Doru, I don`t think so. Please post to this mailing list if you find such table/grid morph. I am using the SGrid package found at map.squeak.org, I wokks in Pharo as well as Squeak 3.10. You will be able to display an array of arrays of objects prividing the column names and a list of selectors to be sent to each cell. The simple example code is as follows: | table | table := (GridMorph from: #(joe jack ben sam mary sally jen) performing: #(asString reverse allButFirst asHex hash)) title: 'Simple Tab table openInWorld. ^ table Find attached the screenshot resulting from this code. I atempted to add per-column alinmgent to Sgrid but stumbled with my lack of morphic frameworl development knowledge. If you are interested in building on top of SGrid, I will be interested in collaborating (providing specifications, teet cases). Carlos -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Tudor Girba Enviado el: Sabado, 01 de Agosto de 2009 08:57 p.m. Para: Pharo Development Asunto: [Pharo-project] table widget Hi, Is there a table widget in Morphic/Polymorph? I would features like: - add columns - sort the rows based on a column - select a row Cheers, Doru -- www.tudorgirba.com "We cannot reach the flow of things unless we let go." _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date: 10/03/2008 11:07 a.m.

Aug. 2, 2009

Re: [Pharo-project] Pharo name format

by Damien Cassou

On Sat, Aug 1, 2009 at 11:24 PM, Marcus Denker<denker(a)acm.org> wrote: > Yes, we need to be better in changelog management. We need: > > Â Â Â Â -> A Blog on the pharo CMS for posting all the things there > Â Â Â Â Â Â in addition to the [update] posts (beeing worked on, should > Â Â Â Â Â Â be ready next week) > Â Â Â Â -> A ChangeLog.txt with every zip. > Â Â Â Â -> A changelog available on the downloads page. > Would you be interested in a diff between mcz versions installed? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 2, 2009

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Adrian Lienhard

On Aug 1, 2009, at 18:33 , Marcus Denker wrote: > > On 01.08.2009, at 07:06, Serge Stinckwich wrote: > >> On Sat, Aug 1, 2009 at 2:41 AM, StÃ©phane >> Ducasse<stephane.ducasse(a)inria.fr> wrote: >>> So what is the process now? >>> Do we focus on 1.0? >>> Can we integrate other issues? >>> Do we have a separate stream for 1.1 alpha? >> >> Maybe the 1.1 alpha should be available after the release of Pharo >> 1.0 >> so the efforts of the team is not disseminate on two versions. > > Yes, I think this is the way to go... we should force everyone to use > the > beta version for a while. Yes. We have 50 open issues for 1.0 and when more people start using Pharo, they will find more bugs. So for now we should focus on bringing that number down to 0. Adrian > > Marcus > > > > > -- > Marcus Denker - http://marcusdenker.de > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 2, 2009

Re: [Pharo-project] [squeak-dev] [ANN] Squeak OpenVG bingings

by Michael Rueger

Igor Stasenko wrote: > Hello guys, > > this is a small project to enable a fast & standard 2D vector graphics > API for squeak - OpenVG. How does OpenVG compare to Cairo in terms of capabilities? How different are the resulting graphics on different platforms? Sounds like to good thing to have nevertheless :-) Would be interesting to integrate the OpenVG binding into the Rome Canvas hierarchy. Michael

Aug. 2, 2009

Re: [Pharo-project] Debbuging problems, FFI

by Javier PimÃ¡s

I Think I found where the problem lies, it's just sitting there waiting to be resolved. To see what was happening I debugged the debuger, which was really weird. I found the answer when I broke into the step over button by adding a self break in OTCmdOverDebugger>>execute. After catching it I removed the break and stepped into everything to see how step over worked. The intresting part is in MethodContext(ContextPart)>>step, which sends interpretNextInstructionFor: self. The idea is this, instead of advancing the vm program counter within the vm code, the debugger simulates the execution cycle, step by step. It not so hard as it seems but also not very simple. The problem comes when the debugger tryies to simulate primitive calls. When the simulator detects a primitive, it issues a MethodContext(ContextPart)>>doPrimitive:method:receiver:args:, here you can see the detection: tryPrimitiveFor: method receiver: receiver args: arguments "..." | primIndex | (primIndex := method primitive) = 0 ifTrue: [^ PrimitiveFailToken]. ^ self doPrimitive: primIndex method: method receiver: receiver args: arguments well, the problem is that doPrimitive doesn't seem to implement all primitives (I recomend you to look it's code), but just a few ones. Also, as far as I can see, it calls primitive 19, which i found is (by looking vm C code) primitiveFail, and that primitive just sets a flag that says that something failed. Then, if my calculations are correct, the problem is that the FFI Call primitive needs to be handled by hand. I tryied adding this to ContextPart>>doPrimitive:method:receiver:args: primitiveIndex = 120 ifTrue: "Calling an FFI method, just evaluate it and return" [ meth valueWithReceiver: receiver arguments: arguments . ^self]. just before arguments size > 6 ifTrue: [^PrimitiveFailToken]. which I think almost worked. I think the primitive was executed, but this doesn't handle the execution context that is being simulated, and the stack gets corrupted. Somebody with more experience in ContextPart, MethodContext, etc. may give us a hand here, I think the fix is almost there. Bye, Javier. 2009/7/31 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2009/7/31 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > >> Does anybody know if the problem occurs just in Windows or in any OS? this >> can give a clue of the problem... >> >> > I don't remember debugging in Windows, but in Linux I have this problem for > sure. > > >> >> On Thu, Jul 30, 2009 at 11:28 PM, Javier PimÃ¡s < >> elpochodelagente(a)gmail.com> wrote: >> >>> Well, at least I feel better that I'm not crazy, (or not the only >>> one...). Maybe if someone could give us a clue about it, we could spot where >>> the problem is. Do you think it is a vm problem or something related to the >>> smalltalk code? >>> >>> 2009/7/30 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>> Yes. This is really annoying for me. I am writing a C library plugin >>>> since a year and a half and this is very frustrated :( >>>> You cannot debug when using FFI. I mean, you cannot get advantages of >>>> one of the best Smalltalk features! What I do is to write a self break >>>> before and after the call and use "proceed" but I don't like it at all. >>>> >>>> Once I tried to see what the problem was, but I was to difficult to me >>>> to understand it and fix it. We need a guru here I think hahaha. >>>> >>>> Best, >>>> >>>> Mariano >>>> >>>> 2009/7/30 Javier PimÃ¡s <elpochodelagente(a)gmail.com> >>>> >>>>> Hi, I'm having problems with the debugger. Every time I try to debug >>>>> code that uses FFI, if I step over a message that internally does an FFI >>>>> call, I get an externalCallFailed error and then I land in >>>>> MethodContext(ContextPart)>>runUntilErrorOrReturnFrom: >>>>> If I run the code without debugging, then I have no problems at all. >>>>> >>>>> I'm using SqueakPharo v3.11.2 with pharo0.1-10373web09.07.2. >>>>> >>>>> To reproduce it you can try this: >>>>> >>>>> ScriptLoader loadFFI. >>>>> then load latest GLMorphic from squeaksource, and uncomment the "self >>>>> break." in >>>>> GLCanvas>>displayString:from:to:at:strikeFont:kern: >>>>> >>>>> doit >>>>> World fullDrawOn: GLDisplayScreen testCanvas >>>>> hit debug and step over until you reach >>>>> ogl glTexImage2D: GLTexture2d with:... >>>>> >>>>> also you'll see wrong values for local vars, like aPoint which will >>>>> look as #(nil nil nil nil nil) when it'll actually have a point. >>>>> >>>>> Is there any other way to set up a break point instead of adding self >>>>> break to the code?? >>>>> >>>>> Thanks, >>>>> Javier. >>>>> >>>>> -- >>>>> Javier PimÃ¡s >>>>> Ciudad de Buenos Aires >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Javier PimÃ¡s >>> Ciudad de Buenos Aires >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> _______________________________________________ >> 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 > -- Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 2, 2009

Re: [Pharo-project] #remoteHostAddress

by Schwab,Wilhelm K

Carlos, No worries. I **agree** with you about 'localhost' - that should resolve to the standard value if at all possible. When one gets "the" local IP number and asks for the name of that, then the (first) fully qualified DNS entry would be the natural choice. My point is simply that it is easy to say "change your network configuration," but what if one is lucky to get enough IT support to make a DNS entry, let alone investigate subtle points of the network configuration to make it work. I had huge problems with this, much of which came from Windows itself, and probably some from other sources to remain nameless. There is weirdness here that goes beyond my failure to send the (anachronistic IMHO) #initializeNetwork before doing the lookup on a LINUX MACHINE. Another bug, I know, but it's easy to blame the network; it's harder to fix it sometimes, especially when it's not at fault. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 6:37 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #remoteHostAddress Bill, I dont see a problem if Pharo features some alternate mechanism that may change the result of resolving localhost to another address. I would not insist, localhost is something I associate to a reserved word - perhaps is too much saying localhost comes from a standard Carlos -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: SÃ¡bado, 01 de Agosto de 2009 03:13 p.m. Para: Pharo-project(a)lists.gforge.inria.fr Asunto: Re: [Pharo-project] #remoteHostAddress Carlos, What if one cannot (admin rights) or simply does not wish to be bothered tweaking configurations? I found a goofy sequence of operations that correctly resolved local names, at least on Windows, and will eventually replicate that in Pharo. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 12:40 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #remoteHostAddress I agree. localhost bound to the loop address is the ip atandard, and based on the stack implementation you run on, you may wish to define localhost to resolve different, you haev the configuration files to change that -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: SÃ¡bado, 01 de Agosto de 2009 02:13 p.m. Para: Pharo-project(a)lists.gforge.inria.fr Asunto: Re: [Pharo-project] #remoteHostAddress For 'localhost', sure, 127.0.0.1 is probably the correct response. However, one can also run into situations of needing to find "the" current IP number/name. There are also servers with multiple addresses, and numbers with multiple names. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: Pharo-project(a)lists.gforge.inria.fr; johnmci(a)smalltalkconsulting.com Subject: Re: [Pharo-project] #remoteHostAddress Yes, wouldn't you expect 127.0.0.1 as the response from: NetNameResolver addressForName: 'localhost' ? On Fri, Jul 31, 2009 at 3:52 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> wrote: Well that does ^NetNameResolver addressForName: self localHostName where self localHostName on my machine returns 'Otter-2.local' where it really does addressesForName: and then if there is more than one then addresses first socketAddress So for my mac it's fe80::21c:42ff:fe00:9%en5(Otter-2), 0(0)-inet6-stream-tcp fe80::21c:42ff:fe00:8%en5(fe80::21c: 42ff:fe00:8%en5), 0(0)-inet6-stream-tcp fe80::21b:63ff:fe02:d2db%en5(fe80::21b: 63ff:fe02:d2db%en5), 0(0)-inet6-stream-tcp 10.37.129.2(10.37.129.2), 0(0)-inet4-stream-tcp 10.211.55.2(10.211.55.2), 0(0)-inet4-stream-tcp 192.168.1.139(192.168.1.139), 0(0)-inet4-stream-tcp where it has 4 ipv 6 address and 3 ipv 4 addresses. and doing NetNameResolver localHostAddress then gives: fe80::21c:42ff:fe00:9%en5(Otter-2),0(0) The problem then is figuring out what you want, versus grabbing the first element in the list of IP address serviced by the machine. Perhaps in this case you thought you should get 192.168.1.139? Now if I ask for ^NetNameResolver addressForName: 'localhost' then I get back ::1(localhost),0(0) On 30-Jul-09, at 2:07 PM, Ramiro Diaz Trepat wrote: > Sorry, this mail came out too quick. How to report the error is a > secondary matter. > I believe the issue is about localhost name resolution. I think > this was discussed around the Windows VM platform, but I am on a Mac. > > > NetNameResolver addressForName: 'localhost' > > does not return 127.0.0.1 > > And, > > NetNameResolver localHostAddress > > returns the address on the network leg (192.168.....) instead of > 127.0.0.1 > > Is the convention that localhost is always 127.0.0.1 ? > > > Cheers > > > r. > > > On Thu, Jul 30, 2009 at 9:20 PM, Ramiro Diaz Trepat <ramiro(a)diaztrepat.name<mailto:ramiro@diaztrepat.name> > > wrote: > I am trying to port Magma to Pharo, and I have run across the > following issue. > > Ini Pharo, the method: > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mir 6/17/2007 20:10) > > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , self remoteHostAddress hostNumber , ':' , port asString] > > > #remoteHostAddress has no implementors in Pharo. > > The implementation of this method in Squeak uses NetNameResolver > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mu 8/14/2003 15:15) > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , (NetNameResolver stringFromAddress: hostAddress) , ':' , port > asString] > > Who is maintaining Socket now in Pharo? > Has anyone got some advice on how to solve this? > Cheers > > r. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 2, 2009

[Pharo-project] table widget

by Tudor Girba

Hi, Is there a table widget in Morphic/Polymorph? I would features like: - add columns - sort the rows based on a column - select a row Cheers, Doru -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

Aug. 1, 2009

Re: [Pharo-project] #remoteHostAddress

by Carlos Crosetti

Bill, I dont see a problem if Pharo features some alternate mechanism that may change the result of resolving localhost to another address. I would not insist, localhost is something I associate to a reserved word - perhaps is too much saying localhost comes from a standard Carlos -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: SÃ¡bado, 01 de Agosto de 2009 03:13 p.m. Para: Pharo-project(a)lists.gforge.inria.fr Asunto: Re: [Pharo-project] #remoteHostAddress Carlos, What if one cannot (admin rights) or simply does not wish to be bothered tweaking configurations? I found a goofy sequence of operations that correctly resolved local names, at least on Windows, and will eventually replicate that in Pharo. Bill ---------------------------------------------------------------------------- -- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 12:40 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #remoteHostAddress I agree. localhost bound to the loop address is the ip atandard, and based on the stack implementation you run on, you may wish to define localhost to resolve different, you haev the configuration files to change that -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: SÃ¡bado, 01 de Agosto de 2009 02:13 p.m. Para: Pharo-project(a)lists.gforge.inria.fr Asunto: Re: [Pharo-project] #remoteHostAddress For 'localhost', sure, 127.0.0.1 is probably the correct response. However, one can also run into situations of needing to find "the" current IP number/name. There are also servers with multiple addresses, and numbers with multiple names. ---------------------------------------------------------------------------- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: Pharo-project(a)lists.gforge.inria.fr; johnmci(a)smalltalkconsulting.com Subject: Re: [Pharo-project] #remoteHostAddress Yes, wouldn't you expect 127.0.0.1 as the response from: NetNameResolver addressForName: 'localhost' ? On Fri, Jul 31, 2009 at 3:52 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: Well that does ^NetNameResolver addressForName: self localHostName where self localHostName on my machine returns 'Otter-2.local' where it really does addressesForName: and then if there is more than one then addresses first socketAddress So for my mac it's fe80::21c:42ff:fe00:9%en5(Otter-2), 0(0)-inet6-stream-tcp fe80::21c:42ff:fe00:8%en5(fe80::21c: 42ff:fe00:8%en5), 0(0)-inet6-stream-tcp fe80::21b:63ff:fe02:d2db%en5(fe80::21b: 63ff:fe02:d2db%en5), 0(0)-inet6-stream-tcp 10.37.129.2(10.37.129.2), 0(0)-inet4-stream-tcp 10.211.55.2(10.211.55.2), 0(0)-inet4-stream-tcp 192.168.1.139(192.168.1.139), 0(0)-inet4-stream-tcp where it has 4 ipv 6 address and 3 ipv 4 addresses. and doing NetNameResolver localHostAddress then gives: fe80::21c:42ff:fe00:9%en5(Otter-2),0(0) The problem then is figuring out what you want, versus grabbing the first element in the list of IP address serviced by the machine. Perhaps in this case you thought you should get 192.168.1.139? Now if I ask for ^NetNameResolver addressForName: 'localhost' then I get back ::1(localhost),0(0) On 30-Jul-09, at 2:07 PM, Ramiro Diaz Trepat wrote: > Sorry, this mail came out too quick. How to report the error is a > secondary matter. > I believe the issue is about localhost name resolution. I think > this was discussed around the Windows VM platform, but I am on a Mac. > > > NetNameResolver addressForName: 'localhost' > > does not return 127.0.0.1 > > And, > > NetNameResolver localHostAddress > > returns the address on the network leg (192.168.....) instead of > 127.0.0.1 > > Is the convention that localhost is always 127.0.0.1 ? > > > Cheers > > > r. > > > On Thu, Jul 30, 2009 at 9:20 PM, Ramiro Diaz Trepat <ramiro(a)diaztrepat.name > > wrote: > I am trying to port Magma to Pharo, and I have run across the > following issue. > > Ini Pharo, the method: > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mir 6/17/2007 20:10) > > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , self remoteHostAddress hostNumber , ':' , port asString] > > > #remoteHostAddress has no implementors in Pharo. > > The implementation of this method in Squeak uses NetNameResolver > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mu 8/14/2003 15:15) > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , (NetNameResolver stringFromAddress: hostAddress) , ':' , port > asString] > > Who is maintaining Socket now in Pharo? > Has anyone got some advice on how to solve this? > Cheers > > r. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ====================================================================== == John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ====================================================================== == _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 1, 2009