NetNameResolver in Pharo 1.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

NetNameResolver in Pharo 1.1

Lukas Renggli
In Pharo 1.0 there were some problems with the network stack (namely
the NetNameResolver) and the IP6 code was reverted shortly before
release, see the following issue for details:

     http://code.google.com/p/pharo/issues/detail?id=1884

Today I was checking with Stef for the presence of these problems in
Pharo 1.1, but we could not reproduce neither on Mac, Windows nor
Linux. Does anybody have problems with the following expressions in
Pharo 1.1?

    NetNameResolver localHostAddress.
    NetNameResolver addressForName: 'www.yahoo.com'.

Or are we doing the wrong thing to reproduce?

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Michael Roberts-2
We should run the Magma test suite.

It was not just related to those NetNameResolver methods IIRC. The API
changed very slightly.  Also, the lazy initialization of useOldNetwork
made it really difficult to see what was going on.

I'll have a dig around.

cheers,
Mike

On Sat, May 8, 2010 at 4:54 PM, Lukas Renggli <[hidden email]> wrote:

> In Pharo 1.0 there were some problems with the network stack (namely
> the NetNameResolver) and the IP6 code was reverted shortly before
> release, see the following issue for details:
>
>     http://code.google.com/p/pharo/issues/detail?id=1884
>
> Today I was checking with Stef for the presence of these problems in
> Pharo 1.1, but we could not reproduce neither on Mac, Windows nor
> Linux. Does anybody have problems with the following expressions in
> Pharo 1.1?
>
>    NetNameResolver localHostAddress.
>    NetNameResolver addressForName: 'www.yahoo.com'.
>
> Or are we doing the wrong thing to reproduce?
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Lukas Renggli
> We should run the Magma test suite.

Could you do that?

> It was not just related to those NetNameResolver methods IIRC. The API
> changed very slightly.  Also, the lazy initialization of useOldNetwork
> made it really difficult to see what was going on.

In my experiments #useOldNetwork was always 'false' on all platforms
(Mac, Linux and Windows). Is this something that depends on the VM?
Maybe we should rather remove the old network code and throw an error
if somebody is using an old VM that doesn't support the new
primitives.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Michael Roberts-2
On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <[hidden email]> wrote:
>> We should run the Magma test suite.
>
> Could you do that?

Yes, i'm just asking Chris what the latest packages are. My emails on
the subject don't seem to match the repository any more.

>
>> It was not just related to those NetNameResolver methods IIRC. The API
>> changed very slightly.  Also, the lazy initialization of useOldNetwork
>> made it really difficult to see what was going on.
>
> In my experiments #useOldNetwork was always 'false' on all platforms
> (Mac, Linux and Windows). Is this something that depends on the VM?

I don't think so. I think it could just get into an odd state. Perhaps
when using OSProcess to spawn/fork new images?


> Maybe we should rather remove the old network code and throw an error
> if somebody is using an old VM that doesn't support the new
> primitives.

I would really like to remove the old network code. Definitely remove
the switch and all the parallel code paths.  Also, to me the network
should be initialized on image startup once, and not when the first
message is sent to the network classes.  There are far too many checks
for it.  We need to be careful what the old and new API are. this is
where documentation would really help.

I ran your methods quickly.  I'm a bit confused. NetNameResolver is
now only returning a single address on my machine whereas before it
returned a list of many for the local host. This was part of the
problem, in that there was no order.  There are various threads on it.
 But what changed to cause this? Did we change 1.1 or the VM has a
small change?  i didn't track either.

cheers,
Mike

>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Schwab,Wilhelm K
Mike,

I completely agree that Pharo needs a clear sense of when it starts, and that network inititialization should happen then.  Shutting down and restarting everything on image save is just wrong.  Dolphin does all of this correctly; the key to which is to be willing to save an image that will "wake up" with garbage pointers, but will (because it realizes it is starting) clear all of that and re-initialize (often lazily) so everything is correct in the new session.  Image saves are not relevant to cleanup in that case.  It drove me nuts for a while, but I came to realize that it is the correct approach; one of many in Dolphin's design.

One caveat that we should consider: the weird state of network initialization is perhaps not just due to the absense of session management in Squeak.  It has been explained (Guzdial and Rose??) as being done in deference to some platforms that would react badly to premature network initialization.  Is this just to allow dialup connections on some long-extinct platform?  Is it just an excuse to provide cover for Squeak's lack of session management?  Is it something that made some sense in 1995, but it obsolete in 2010?  Sorry to be so blunt, but there might actually be a good reason for it (perhaps one that is no longer worth the cost) and we won't be able to decide that until we grapple with the truth on both sides.

Another possibility: suppose that to do dialup on your ENIAC, there are problems with #initializeNetwork if it is called before you change the computer's oil.  The problems might be real on some platforms.  Does that mean that broadband-enabled Windows, Mac and Linux users all have to suffer because somebody has a museum piece somewhere?  The answer might be to provide a command line option to defer initialization until the system is ready, but otherwise to do it once on startup.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Roberts
Sent: Sunday, May 09, 2010 3:21 AM
To: [hidden email]
Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1

On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <[hidden email]> wrote:
>> We should run the Magma test suite.
>
> Could you do that?

Yes, i'm just asking Chris what the latest packages are. My emails on the subject don't seem to match the repository any more.

>
>> It was not just related to those NetNameResolver methods IIRC. The
>> API changed very slightly.  Also, the lazy initialization of
>> useOldNetwork made it really difficult to see what was going on.
>
> In my experiments #useOldNetwork was always 'false' on all platforms
> (Mac, Linux and Windows). Is this something that depends on the VM?

I don't think so. I think it could just get into an odd state. Perhaps when using OSProcess to spawn/fork new images?


> Maybe we should rather remove the old network code and throw an error
> if somebody is using an old VM that doesn't support the new
> primitives.

I would really like to remove the old network code. Definitely remove the switch and all the parallel code paths.  Also, to me the network should be initialized on image startup once, and not when the first message is sent to the network classes.  There are far too many checks for it.  We need to be careful what the old and new API are. this is where documentation would really help.

I ran your methods quickly.  I'm a bit confused. NetNameResolver is now only returning a single address on my machine whereas before it returned a list of many for the local host. This was part of the problem, in that there was no order.  There are various threads on it.
 But what changed to cause this? Did we change 1.1 or the VM has a small change?  i didn't track either.

cheers,
Mike

>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Stéphane Ducasse
yes and we accept code :)

On May 9, 2010, at 2:41 PM, Schwab,Wilhelm K wrote:

> Mike,
>
> I completely agree that Pharo needs a clear sense of when it starts, and that network inititialization should happen then.  Shutting down and restarting everything on image save is just wrong.  Dolphin does all of this correctly; the key to which is to be willing to save an image that will "wake up" with garbage pointers, but will (because it realizes it is starting) clear all of that and re-initialize (often lazily) so everything is correct in the new session.  Image saves are not relevant to cleanup in that case.  It drove me nuts for a while, but I came to realize that it is the correct approach; one of many in Dolphin's design.
>
> One caveat that we should consider: the weird state of network initialization is perhaps not just due to the absense of session management in Squeak.  It has been explained (Guzdial and Rose??) as being done in deference to some platforms that would react badly to premature network initialization.  Is this just to allow dialup connections on some long-extinct platform?  Is it just an excuse to provide cover for Squeak's lack of session management?  Is it something that made some sense in 1995, but it obsolete in 2010?  Sorry to be so blunt, but there might actually be a good reason for it (perhaps one that is no longer worth the cost) and we won't be able to decide that until we grapple with the truth on both sides.
>
> Another possibility: suppose that to do dialup on your ENIAC, there are problems with #initializeNetwork if it is called before you change the computer's oil.  The problems might be real on some platforms.  Does that mean that broadband-enabled Windows, Mac and Linux users all have to suffer because somebody has a museum piece somewhere?  The answer might be to provide a command line option to defer initialization until the system is ready, but otherwise to do it once on startup.
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Roberts
> Sent: Sunday, May 09, 2010 3:21 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1
>
> On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <[hidden email]> wrote:
>>> We should run the Magma test suite.
>>
>> Could you do that?
>
> Yes, i'm just asking Chris what the latest packages are. My emails on the subject don't seem to match the repository any more.
>
>>
>>> It was not just related to those NetNameResolver methods IIRC. The
>>> API changed very slightly.  Also, the lazy initialization of
>>> useOldNetwork made it really difficult to see what was going on.
>>
>> In my experiments #useOldNetwork was always 'false' on all platforms
>> (Mac, Linux and Windows). Is this something that depends on the VM?
>
> I don't think so. I think it could just get into an odd state. Perhaps when using OSProcess to spawn/fork new images?
>
>
>> Maybe we should rather remove the old network code and throw an error
>> if somebody is using an old VM that doesn't support the new
>> primitives.
>
> I would really like to remove the old network code. Definitely remove the switch and all the parallel code paths.  Also, to me the network should be initialized on image startup once, and not when the first message is sent to the network classes.  There are far too many checks for it.  We need to be careful what the old and new API are. this is where documentation would really help.
>
> I ran your methods quickly.  I'm a bit confused. NetNameResolver is now only returning a single address on my machine whereas before it returned a list of many for the local host. This was part of the problem, in that there was no order.  There are various threads on it.
> But what changed to cause this? Did we change 1.1 or the VM has a small change?  i didn't track either.
>
> cheers,
> Mike
>
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Schwab,Wilhelm K
Stef,

Speaking of code, I have a fair bit of it that I need to check for slips and make available.  The slips that are relevant would be anything in comments that might violate non-disclosure agreements[*].  What I need is something/anything that produces syntax colored output given a package name.  The idea is that anything in the comment color needs careful scrutiny.  Even colored html files that I could view in a web browser would probably do the trick.  There was some mention that Seaside might already do this??  I will eventually look for or build something to do it, but pointers would be appreciated.

[*] I try to be careful about it now, but sometimes run across old comments that were not for public consumption.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Sunday, May 09, 2010 9:33 AM
To: [hidden email]
Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1

yes and we accept code :)

On May 9, 2010, at 2:41 PM, Schwab,Wilhelm K wrote:

> Mike,
>
> I completely agree that Pharo needs a clear sense of when it starts, and that network inititialization should happen then.  Shutting down and restarting everything on image save is just wrong.  Dolphin does all of this correctly; the key to which is to be willing to save an image that will "wake up" with garbage pointers, but will (because it realizes it is starting) clear all of that and re-initialize (often lazily) so everything is correct in the new session.  Image saves are not relevant to cleanup in that case.  It drove me nuts for a while, but I came to realize that it is the correct approach; one of many in Dolphin's design.
>
> One caveat that we should consider: the weird state of network initialization is perhaps not just due to the absense of session management in Squeak.  It has been explained (Guzdial and Rose??) as being done in deference to some platforms that would react badly to premature network initialization.  Is this just to allow dialup connections on some long-extinct platform?  Is it just an excuse to provide cover for Squeak's lack of session management?  Is it something that made some sense in 1995, but it obsolete in 2010?  Sorry to be so blunt, but there might actually be a good reason for it (perhaps one that is no longer worth the cost) and we won't be able to decide that until we grapple with the truth on both sides.
>
> Another possibility: suppose that to do dialup on your ENIAC, there are problems with #initializeNetwork if it is called before you change the computer's oil.  The problems might be real on some platforms.  Does that mean that broadband-enabled Windows, Mac and Linux users all have to suffer because somebody has a museum piece somewhere?  The answer might be to provide a command line option to defer initialization until the system is ready, but otherwise to do it once on startup.
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Michael Roberts
> Sent: Sunday, May 09, 2010 3:21 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1
>
> On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <[hidden email]> wrote:
>>> We should run the Magma test suite.
>>
>> Could you do that?
>
> Yes, i'm just asking Chris what the latest packages are. My emails on the subject don't seem to match the repository any more.
>
>>
>>> It was not just related to those NetNameResolver methods IIRC. The
>>> API changed very slightly.  Also, the lazy initialization of
>>> useOldNetwork made it really difficult to see what was going on.
>>
>> In my experiments #useOldNetwork was always 'false' on all platforms
>> (Mac, Linux and Windows). Is this something that depends on the VM?
>
> I don't think so. I think it could just get into an odd state. Perhaps when using OSProcess to spawn/fork new images?
>
>
>> Maybe we should rather remove the old network code and throw an error
>> if somebody is using an old VM that doesn't support the new
>> primitives.
>
> I would really like to remove the old network code. Definitely remove the switch and all the parallel code paths.  Also, to me the network should be initialized on image startup once, and not when the first message is sent to the network classes.  There are far too many checks for it.  We need to be careful what the old and new API are. this is where documentation would really help.
>
> I ran your methods quickly.  I'm a bit confused. NetNameResolver is now only returning a single address on my machine whereas before it returned a list of many for the local host. This was part of the problem, in that there was no order.  There are various threads on it.
> But what changed to cause this? Did we change 1.1 or the VM has a small change?  i didn't track either.
>
> cheers,
> Mike
>
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Michael Roberts-2
I have tried to load Magma in Pharo1.1 but have not yet succeeded. I
don't have a lot of time i'm afraid. the existing Metacello config
doesn't load the right packages, nor the list on the wiki page (using
installer) it seems. I am missing an implementation of a method
maAt:ifPresent:ifAbsent: on Smalltalk.

anyone with a spare moment might like to figure that out. The
underscores need fixing in dependent packages (write barrier tests)
as well

so we should maybe do something simpler to test the network.

thanks,
Mike

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Stéphane Ducasse
thanks mike
indeed we should find a better way to tests network problems.

Stef

On May 13, 2010, at 7:53 PM, Michael Roberts wrote:

> I have tried to load Magma in Pharo1.1 but have not yet succeeded. I
> don't have a lot of time i'm afraid. the existing Metacello config
> doesn't load the right packages, nor the list on the wiki page (using
> installer) it seems. I am missing an implementation of a method
> maAt:ifPresent:ifAbsent: on Smalltalk.
>
> anyone with a spare moment might like to figure that out. The
> underscores need fixing in dependent packages (write barrier tests)
> as well
>
> so we should maybe do something simpler to test the network.
>
> thanks,
> Mike
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Michael Roberts-2
I thought initially we could do something with netcat and some
scripts. But that is a bit limiting on the local host.

Ideally we build a test server providing a bunch of network services
that would respond to example protocols.

I imagine somewhere there is a project that already does this.  Most
linux distros have all the tools anyway (ftp, http, etc). it seems
just a question of configuration and locking-down.

cheers,
Mike

On Thu, May 13, 2010 at 7:24 PM, Stéphane Ducasse
<[hidden email]> wrote:

> thanks mike
> indeed we should find a better way to tests network problems.
>
> Stef
>
> On May 13, 2010, at 7:53 PM, Michael Roberts wrote:
>
>> I have tried to load Magma in Pharo1.1 but have not yet succeeded. I
>> don't have a lot of time i'm afraid. the existing Metacello config
>> doesn't load the right packages, nor the list on the wiki page (using
>> installer) it seems. I am missing an implementation of a method
>> maAt:ifPresent:ifAbsent: on Smalltalk.
>>
>> anyone with a spare moment might like to figure that out. The
>> underscores need fixing in dependent packages (write barrier tests)
>> as well
>>
>> so we should maybe do something simpler to test the network.
>>
>> thanks,
>> Mike
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Chris Muller-3
In reply to this post by Michael Roberts-2
> installer) it seems. I am missing an implementation of a method
> maAt:ifPresent:ifAbsent: on Smalltalk.

Hi Mike, this is left-over from when Smalltalk became a
SmalltalkImage.  But I am confused because I thought I had those all
cleaned up.  Indeed, I did not find any senders of that to Smalltalk.

Were you just trying to load it or run the test suite?  If you would
post the stack I would be able to see what you were trying to do and
would be happy to fix it.

 - Chris

>
> anyone with a spare moment might like to figure that out. The
> underscores need fixing in dependent packages (write barrier tests)
> as well
>
> so we should maybe do something simpler to test the network.
>
> thanks,
> Mike
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Michael Roberts-2
Hi just trying to run the tests via the standard magma test
expression. So it is looking to see if Display exists. That's the
point on my mac I recognize that it annoyingly changes my screen
resolution :-)

anyway it is missing your ma extension to query the namespace.

Cheers
mike

On Friday, May 14, 2010, Chris Muller <[hidden email]> wrote:

>> installer) it seems. I am missing an implementation of a method
>> maAt:ifPresent:ifAbsent: on Smalltalk.
>
> Hi Mike, this is left-over from when Smalltalk became a
> SmalltalkImage.  But I am confused because I thought I had those all
> cleaned up.  Indeed, I did not find any senders of that to Smalltalk.
>
> Were you just trying to load it or run the test suite?  If you would
> post the stack I would be able to see what you were trying to do and
> would be happy to fix it.
>
>  - Chris
>
>>
>> anyone with a spare moment might like to figure that out. The
>> underscores need fixing in dependent packages (write barrier tests)
>> as well
>>
>> so we should maybe do something simpler to test the network.
>>
>> thanks,
>> Mike
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Chris Muller-4
You have an out-of-date version of "Ma Armored Code" package.  It
sounds like you are not using instructions on the Magma installation
page..?

 http://wiki.squeak.org/squeak/2657

The Installer script provided there is correct, I'm not sure what happened..

You could also use Monticello Configurations, but they appear to not
be working in Pharo 1.1 right now.  I don't know whether Miguel
updated his Metacello config for Magma; I have not yet had time to get
into Metacello or I would have done it.

So how did you install this?


On Fri, May 14, 2010 at 9:43 AM, Michael Roberts <[hidden email]> wrote:

> Hi just trying to run the tests via the standard magma test
> expression. So it is looking to see if Display exists. That's the
> point on my mac I recognize that it annoyingly changes my screen
> resolution :-)
>
> anyway it is missing your ma extension to query the namespace.
>
> Cheers
> mike
>
> On Friday, May 14, 2010, Chris Muller <[hidden email]> wrote:
>>> installer) it seems. I am missing an implementation of a method
>>> maAt:ifPresent:ifAbsent: on Smalltalk.
>>
>> Hi Mike, this is left-over from when Smalltalk became a
>> SmalltalkImage.  But I am confused because I thought I had those all
>> cleaned up.  Indeed, I did not find any senders of that to Smalltalk.
>>
>> Were you just trying to load it or run the test suite?  If you would
>> post the stack I would be able to see what you were trying to do and
>> would be happy to fix it.
>>
>>  - Chris
>>
>>>
>>> anyone with a spare moment might like to figure that out. The
>>> underscores need fixing in dependent packages (write barrier tests)
>>> as well
>>>
>>> so we should maybe do something simpler to test the network.
>>>
>>> thanks,
>>> Mike
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Fwd: NetNameResolver in Pharo 1.1

Michael Roberts-2
I first tried the metacello package but it didn't work. I then tried
the installer script but I didn't have installer loaded. So I found a
copy of installer installed that and then ran the update script
exactly from the wiki page. It didn't work. I mean it installed a
bunch of stuff but is still missing the method.

I am happy to test it again when someone correctly packages it for pharo 1.1.

Cheers mike

On Friday, May 14, 2010, Chris Muller <[hidden email]> wrote:

> You have an out-of-date version of "Ma Armored Code" package.  It
> sounds like you are not using instructions on the Magma installation
> page..?
>
>  http://wiki.squeak.org/squeak/2657
>
> The Installer script provided there is correct, I'm not sure what happened..
>
> You could also use Monticello Configurations, but they appear to not
> be working in Pharo 1.1 right now.  I don't know whether Miguel
> updated his Metacello config for Magma; I have not yet had time to get
> into Metacello or I would have done it.
>
> So how did you install this?
>
>
> On Fri, May 14, 2010 at 9:43 AM, Michael Roberts <[hidden email]> wrote:
>> Hi just trying to run the tests via the standard magma test
>> expression. So it is looking to see if Display exists. That's the
>> point on my mac I recognize that it annoyingly changes my screen
>> resolution :-)
>>
>> anyway it is missing your ma extension to query the namespace.
>>
>> Cheers
>> mike
>>
>> On Friday, May 14, 2010, Chris Muller <[hidden email]> wrote:
>>>> installer) it seems. I am missing an implementation of a method
>>>> maAt:ifPresent:ifAbsent: on Smalltalk.
>>>
>>> Hi Mike, this is left-over from when Smalltalk became a
>>> SmalltalkImage.  But I am confused because I thought I had those all
>>> cleaned up.  Indeed, I did not find any senders of that to Smalltalk.
>>>
>>> Were you just trying to load it or run the test suite?  If you would
>>> post the stack I would be able to see what you were trying to do and
>>> would be happy to fix it.
>>>
>>>  - Chris
>>>
>>>>
>>>> anyone with a spare moment might like to figure that out. The
>>>> underscores need fixing in dependent packages (write barrier tests)
>>>> as well
>>>>
>>>> so we should maybe do something simpler to test the network.
>>>>
>>>> thanks,
>>>> Mike
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Miguel Cobá
In reply to this post by Lukas Renggli
El sáb, 08-05-2010 a las 17:54 +0200, Lukas Renggli escribió:

> In Pharo 1.0 there were some problems with the network stack (namely
> the NetNameResolver) and the IP6 code was reverted shortly before
> release, see the following issue for details:
>
>      http://code.google.com/p/pharo/issues/detail?id=1884
>
> Today I was checking with Stef for the presence of these problems in
> Pharo 1.1, but we could not reproduce neither on Mac, Windows nor
> Linux. Does anybody have problems with the following expressions in
> Pharo 1.1?
>
>     NetNameResolver localHostAddress.
>     NetNameResolver addressForName: 'www.yahoo.com'.
>
> Or are we doing the wrong thing to reproduce?
>
> Lukas

Sorry for arriving late to the party :).
I tried the doits from the problem on Pharo 1.0 in a Pharo Core 11364
image. I got some error, although not as severe as in Pharo 1.0.

I added an issue for this

http://code.google.com/p/pharo/issues/detail?id=2444

Now, I'm going to test with Magma to see if some other error shows

Cheers
--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NetNameResolver in Pharo 1.1

Stéphane Ducasse
MIguel

which version of 1.1 because we rollback the changes so normally we should have now the same as in 1.0

Stef

On May 19, 2010, at 8:48 PM, Miguel Enrique Cobá Martinez wrote:

> El sáb, 08-05-2010 a las 17:54 +0200, Lukas Renggli escribió:
>> In Pharo 1.0 there were some problems with the network stack (namely
>> the NetNameResolver) and the IP6 code was reverted shortly before
>> release, see the following issue for details:
>>
>>     http://code.google.com/p/pharo/issues/detail?id=1884
>>
>> Today I was checking with Stef for the presence of these problems in
>> Pharo 1.1, but we could not reproduce neither on Mac, Windows nor
>> Linux. Does anybody have problems with the following expressions in
>> Pharo 1.1?
>>
>>    NetNameResolver localHostAddress.
>>    NetNameResolver addressForName: 'www.yahoo.com'.
>>
>> Or are we doing the wrong thing to reproduce?
>>
>> Lukas
>
> Sorry for arriving late to the party :).
> I tried the doits from the problem on Pharo 1.0 in a Pharo Core 11364
> image. I got some error, although not as severe as in Pharo 1.0.
>
> I added an issue for this
>
> http://code.google.com/p/pharo/issues/detail?id=2444
>
> Now, I'm going to test with Magma to see if some other error shows
>
> Cheers
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project