Bug in NetNameResolver on PharoCore 10508?

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

Re: Bug in NetNameResolver on PharoCore 10508?

Stéphane Ducasse
+1

>> Yes, I know that the code is very difficult to understand, mainly
> because of the primitives. They brake the understanding you have so far
> when you have to switch to c code with a lot of pointers/structs/string
> buffers.
>
> The problem here is that, now it is impossible to change the networks
> subsystem of Pharo (or squeak). As Mariano said, we *need* to release
> 1.0 and this bug can be a show stopper.
>
> Also, with due respect to the original coders of the network subsystem,
> the code is really convoluted (I know that networking isn't simple), at
> least to understand the fully implication of a "simple" change like
> this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6,
> primitives and smalltalk code. So I think that is difficult to have
> someone with the enough knowledge to change the code so that it works
> for now. But that is how things are now. Maybe our own ignorance of the
> code is what negates us a fix, but we need to left that apart and work a
> solution for the *particular* problem in hand. For 1.1 we can discuss
> new implementation if that is required.
>
> As Adrian said, there are users that need useOldNetwork true and some
> others that need useOldNetwork to false. The problem is that we don't
> fully understand the consequences of both changes.
>
> So, people, we need your help. Those who are most familiar with the
> network code, please, please, take a look and suggest a solution for the
> 1.0 release. *No* full rewrites, no throw code, no blaming, just a
> working workaround for this.
>
> Regards
>
> Miguel Coba
>
> --
> 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
Reply | Threaded
Open this post in threaded view
|

UseOldNetwork possible workaround Was: Re: Bug in NetNameResolver on PharoCore 10508?

Miguel Cobá
In reply to this post by Miguel Cobá

>From Socket class >> initializeNetwork:

        "Initialize the network drivers and the NetNameResolver. Do nothing if
the network is already initialized."
        "Note: The network must be re-initialized every time Squeak starts up,
so applications that persist across snapshots should be prepared to
re-initialize the network as needed. Such applications should call
'Socket initializeNetwork' before every network transaction. "

        NetNameResolver initializeNetwork

This explains why the initializeNetwork must be called *before* every
network transaction. Between image restarts the network isn't guaranteed
to remain.

I propose to create a new preference (I know that they are banned but we
need a workaround for 1.0 release) and then each user can, without
modify the NetNameResolver class >>initializeNetwork, change the setting
to the value that works for him/her.

First evaluate:

Preferences addPreference: #useOldNetwork categories:
#(general network)
    default: false balloonHelp: 'Enable/disable the use of the old
network code in making network connections. You need to save and restart
the image to this preference to take effect'
    projectLocal: false changeInformee: nil changeSelector: nil.

to create the preference in a PharoCore 10508 image.

Then load

Network-Kernel-MiguelCoba.22

from PharoInbox.

Pay attention that when you change the preference, it is not refected
immediately. You need to:

1. Open the image with the wrong value of the Preference
2. Change the preference
 Preferences enable: #useOldNetwork

  or

 Preferences disable: #useOldNetwork
3. Save the image
4. Restart the saved image
5. Evaluate:
NetNameResolver initializeNetwork

 or some way use the network (open a monticello browser for example, so
that initializeNetwork is called)

6. Test that the preference is being used:

NetNameResolver useOldNetwork -> value of preference

7. Test that resolves correctly an address:

NetNameResolver addressForName: 'www.yahoo.com' ->
209.131.36.158(f1.www.vip.sp1.yahoo.com),0(0)

8. Save the new image, now with the new preference.

I added this workaround as a fix to issue 1884 and changed status to
fixed.

Can you give it a try please and if so, generate a new image for
PharoCore?

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: UseOldNetwork possible workaround Was: Re: Bug in NetNameResolver on PharoCore 10508?

Stéphane Ducasse
Really thanks for all your energy on that.
I have some administrative taks to do now but I will give a try just after.

On Jan 28, 2010, at 6:06 PM, Miguel Enrique Cobá Martinez wrote:

>
>> From Socket class >> initializeNetwork:
>
> "Initialize the network drivers and the NetNameResolver. Do nothing if
> the network is already initialized."
> "Note: The network must be re-initialized every time Squeak starts up,
> so applications that persist across snapshots should be prepared to
> re-initialize the network as needed. Such applications should call
> 'Socket initializeNetwork' before every network transaction. "
>
> NetNameResolver initializeNetwork
>
> This explains why the initializeNetwork must be called *before* every
> network transaction. Between image restarts the network isn't guaranteed
> to remain.
>
> I propose to create a new preference (I know that they are banned but we
> need a workaround for 1.0 release) and then each user can, without
> modify the NetNameResolver class >>initializeNetwork, change the setting
> to the value that works for him/her.
>
> First evaluate:
>
> Preferences addPreference: #useOldNetwork categories:
> #(general network)
>    default: false balloonHelp: 'Enable/disable the use of the old
> network code in making network connections. You need to save and restart
> the image to this preference to take effect'
>    projectLocal: false changeInformee: nil changeSelector: nil.
>
> to create the preference in a PharoCore 10508 image.
>
> Then load
>
> Network-Kernel-MiguelCoba.22
>
> from PharoInbox.
>
> Pay attention that when you change the preference, it is not refected
> immediately. You need to:
>
> 1. Open the image with the wrong value of the Preference
> 2. Change the preference
> Preferences enable: #useOldNetwork
>
>  or
>
> Preferences disable: #useOldNetwork
> 3. Save the image
> 4. Restart the saved image
> 5. Evaluate:
> NetNameResolver initializeNetwork
>
> or some way use the network (open a monticello browser for example, so
> that initializeNetwork is called)
>
> 6. Test that the preference is being used:
>
> NetNameResolver useOldNetwork -> value of preference
>
> 7. Test that resolves correctly an address:
>
> NetNameResolver addressForName: 'www.yahoo.com' ->
> 209.131.36.158(f1.www.vip.sp1.yahoo.com),0(0)
>
> 8. Save the new image, now with the new preference.
>
> I added this workaround as a fix to issue 1884 and changed status to
> fixed.
>
> Can you give it a try please and if so, generate a new image for
> PharoCore?
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: UseOldNetwork possible workaround Was: Re: Bug in NetNameResolver on PharoCore 10508?

Mariano Martinez Peck
Thanks Miguel. I tried but here in the residence I have a proxy to with user and password. To use Monticello or whatever, I always need to evaluate this:

HTTPSocket useProxyServerNamed: '10.100.1.4' port: 9090
proxyUser: 'XXX' password: 'YYY'

or

HTTPSocket proxyUser: 'XXX' password: 'YYY'.


The problem is that with NetNameResolver  I cannot get trough the proxy. Do someone know how can I set the username and password so that to use NetNameResolver?

Sorry, I tried to test it ;)

Mariano

On Thu, Jan 28, 2010 at 6:38 PM, Stéphane Ducasse <[hidden email]> wrote:
Really thanks for all your energy on that.
I have some administrative taks to do now but I will give a try just after.

On Jan 28, 2010, at 6:06 PM, Miguel Enrique Cobá Martinez wrote:

>
>> From Socket class >> initializeNetwork:
>
>       "Initialize the network drivers and the NetNameResolver. Do nothing if
> the network is already initialized."
>       "Note: The network must be re-initialized every time Squeak starts up,
> so applications that persist across snapshots should be prepared to
> re-initialize the network as needed. Such applications should call
> 'Socket initializeNetwork' before every network transaction. "
>
>       NetNameResolver initializeNetwork
>
> This explains why the initializeNetwork must be called *before* every
> network transaction. Between image restarts the network isn't guaranteed
> to remain.
>
> I propose to create a new preference (I know that they are banned but we
> need a workaround for 1.0 release) and then each user can, without
> modify the NetNameResolver class >>initializeNetwork, change the setting
> to the value that works for him/her.
>
> First evaluate:
>
> Preferences addPreference: #useOldNetwork categories:
> #(general network)
>    default: false balloonHelp: 'Enable/disable the use of the old
> network code in making network connections. You need to save and restart
> the image to this preference to take effect'
>    projectLocal: false changeInformee: nil changeSelector: nil.
>
> to create the preference in a PharoCore 10508 image.
>
> Then load
>
> Network-Kernel-MiguelCoba.22
>
> from PharoInbox.
>
> Pay attention that when you change the preference, it is not refected
> immediately. You need to:
>
> 1. Open the image with the wrong value of the Preference
> 2. Change the preference
> Preferences enable: #useOldNetwork
>
>  or
>
> Preferences disable: #useOldNetwork
> 3. Save the image
> 4. Restart the saved image
> 5. Evaluate:
> NetNameResolver initializeNetwork
>
> or some way use the network (open a monticello browser for example, so
> that initializeNetwork is called)
>
> 6. Test that the preference is being used:
>
> NetNameResolver useOldNetwork -> value of preference
>
> 7. Test that resolves correctly an address:
>
> NetNameResolver addressForName: 'www.yahoo.com' ->
> 209.131.36.158(f1.www.vip.sp1.yahoo.com),0(0)
>
> 8. Save the new image, now with the new preference.
>
> I added this workaround as a fix to issue 1884 and changed status to
> fixed.
>
> Can you give it a try please and if so, generate a new image for
> PharoCore?
>
> 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


_______________________________________________
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: UseOldNetwork possible workaround Was: Re: Bug in NetNameResolver on PharoCore 10508?

Stéphane Ducasse

> Thanks Miguel. I tried but here in the residence I have a proxy to with user and password. To use Monticello or whatever, I always need to evaluate this:
>
> HTTPSocket useProxyServerNamed: '10.100.1.4' port: 9090
> proxyUser: 'XXX' password: 'YYY'
>
> or
>
> HTTPSocket proxyUser: 'XXX' password: 'YYY'.
>
>
> The problem is that with NetNameResolver  I cannot get trough the proxy. Do someone know how can I set the username and password so that to use NetNameResolver?
>
> Sorry, I tried to test it ;)

mariano did you check the entry torsten just posted

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

Stef

>
> Mariano
>
> On Thu, Jan 28, 2010 at 6:38 PM, Stéphane Ducasse <[hidden email]> wrote:
> Really thanks for all your energy on that.
> I have some administrative taks to do now but I will give a try just after.
>
> On Jan 28, 2010, at 6:06 PM, Miguel Enrique Cobá Martinez wrote:
>
> >
> >> From Socket class >> initializeNetwork:
> >
> >       "Initialize the network drivers and the NetNameResolver. Do nothing if
> > the network is already initialized."
> >       "Note: The network must be re-initialized every time Squeak starts up,
> > so applications that persist across snapshots should be prepared to
> > re-initialize the network as needed. Such applications should call
> > 'Socket initializeNetwork' before every network transaction. "
> >
> >       NetNameResolver initializeNetwork
> >
> > This explains why the initializeNetwork must be called *before* every
> > network transaction. Between image restarts the network isn't guaranteed
> > to remain.
> >
> > I propose to create a new preference (I know that they are banned but we
> > need a workaround for 1.0 release) and then each user can, without
> > modify the NetNameResolver class >>initializeNetwork, change the setting
> > to the value that works for him/her.
> >
> > First evaluate:
> >
> > Preferences addPreference: #useOldNetwork categories:
> > #(general network)
> >    default: false balloonHelp: 'Enable/disable the use of the old
> > network code in making network connections. You need to save and restart
> > the image to this preference to take effect'
> >    projectLocal: false changeInformee: nil changeSelector: nil.
> >
> > to create the preference in a PharoCore 10508 image.
> >
> > Then load
> >
> > Network-Kernel-MiguelCoba.22
> >
> > from PharoInbox.
> >
> > Pay attention that when you change the preference, it is not refected
> > immediately. You need to:
> >
> > 1. Open the image with the wrong value of the Preference
> > 2. Change the preference
> > Preferences enable: #useOldNetwork
> >
> >  or
> >
> > Preferences disable: #useOldNetwork
> > 3. Save the image
> > 4. Restart the saved image
> > 5. Evaluate:
> > NetNameResolver initializeNetwork
> >
> > or some way use the network (open a monticello browser for example, so
> > that initializeNetwork is called)
> >
> > 6. Test that the preference is being used:
> >
> > NetNameResolver useOldNetwork -> value of preference
> >
> > 7. Test that resolves correctly an address:
> >
> > NetNameResolver addressForName: 'www.yahoo.com' ->
> > 209.131.36.158(f1.www.vip.sp1.yahoo.com),0(0)
> >
> > 8. Save the new image, now with the new preference.
> >
> > I added this workaround as a fix to issue 1884 and changed status to
> > fixed.
> >
> > Can you give it a try please and if so, generate a new image for
> > PharoCore?
> >
> > 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
>
> _______________________________________________
> 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: UseOldNetwork possible workaround Was: Re: Bug in NetNameResolver on PharoCore 10508?

Levente Uzonyi-2
In reply to this post by Mariano Martinez Peck
On Thu, 28 Jan 2010, Mariano Martinez Peck wrote:

> Thanks Miguel. I tried but here in the residence I have a proxy to with user
> and password. To use Monticello or whatever, I always need to evaluate this:
>
> HTTPSocket useProxyServerNamed: '10.100.1.4' port: 9090
> proxyUser: 'XXX' password: 'YYY'
>
> or
>
> HTTPSocket proxyUser: 'XXX' password: 'YYY'.
>
>
> The problem is that with NetNameResolver  I cannot get trough the proxy. Do
If you only have an HTTP proxy, DNS won't work (but you don't really need
that, because the proxy will resolve the domain names). So that's normal.


Levente

> someone know how can I set the username and password so that to use
> NetNameResolver?
>
> Sorry, I tried to test it ;)
>
> Mariano
>
> On Thu, Jan 28, 2010 at 6:38 PM, Stéphane Ducasse <[hidden email]
>> wrote:
>
>> Really thanks for all your energy on that.
>> I have some administrative taks to do now but I will give a try just after.
>>
>> On Jan 28, 2010, at 6:06 PM, Miguel Enrique Cobá Martinez wrote:
>>
>>>
>>>> From Socket class >> initializeNetwork:
>>>
>>>       "Initialize the network drivers and the NetNameResolver. Do nothing
>> if
>>> the network is already initialized."
>>>       "Note: The network must be re-initialized every time Squeak starts
>> up,
>>> so applications that persist across snapshots should be prepared to
>>> re-initialize the network as needed. Such applications should call
>>> 'Socket initializeNetwork' before every network transaction. "
>>>
>>>       NetNameResolver initializeNetwork
>>>
>>> This explains why the initializeNetwork must be called *before* every
>>> network transaction. Between image restarts the network isn't guaranteed
>>> to remain.
>>>
>>> I propose to create a new preference (I know that they are banned but we
>>> need a workaround for 1.0 release) and then each user can, without
>>> modify the NetNameResolver class >>initializeNetwork, change the setting
>>> to the value that works for him/her.
>>>
>>> First evaluate:
>>>
>>> Preferences addPreference: #useOldNetwork categories:
>>> #(general network)
>>>    default: false balloonHelp: 'Enable/disable the use of the old
>>> network code in making network connections. You need to save and restart
>>> the image to this preference to take effect'
>>>    projectLocal: false changeInformee: nil changeSelector: nil.
>>>
>>> to create the preference in a PharoCore 10508 image.
>>>
>>> Then load
>>>
>>> Network-Kernel-MiguelCoba.22
>>>
>>> from PharoInbox.
>>>
>>> Pay attention that when you change the preference, it is not refected
>>> immediately. You need to:
>>>
>>> 1. Open the image with the wrong value of the Preference
>>> 2. Change the preference
>>> Preferences enable: #useOldNetwork
>>>
>>>  or
>>>
>>> Preferences disable: #useOldNetwork
>>> 3. Save the image
>>> 4. Restart the saved image
>>> 5. Evaluate:
>>> NetNameResolver initializeNetwork
>>>
>>> or some way use the network (open a monticello browser for example, so
>>> that initializeNetwork is called)
>>>
>>> 6. Test that the preference is being used:
>>>
>>> NetNameResolver useOldNetwork -> value of preference
>>>
>>> 7. Test that resolves correctly an address:
>>>
>>> NetNameResolver addressForName: 'www.yahoo.com' ->
>>> 209.131.36.158(f1.www.vip.sp1.yahoo.com),0(0)
>>>
>>> 8. Save the new image, now with the new preference.
>>>
>>> I added this workaround as a fix to issue 1884 and changed status to
>>> fixed.
>>>
>>> Can you give it a try please and if so, generate a new image for
>>> PharoCore?
>>>
>>> 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
>>
>
_______________________________________________
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: UseOldNetwork possible workaround Was: Re: Bug in NetNameResolver on PharoCore 10508?

Mariano Martinez Peck


2010/1/28 Levente Uzonyi <[hidden email]>
On Thu, 28 Jan 2010, Mariano Martinez Peck wrote:

Thanks Miguel. I tried but here in the residence I have a proxy to with user
and password. To use Monticello or whatever, I always need to evaluate this:

HTTPSocket useProxyServerNamed: '10.100.1.4' port: 9090
proxyUser: 'XXX' password: 'YYY'

or

HTTPSocket proxyUser: 'XXX' password: 'YYY'.


The problem is that with NetNameResolver  I cannot get trough the proxy. Do

If you only have an HTTP proxy, DNS won't work (but you don't really need that, because the proxy will resolve the domain names). So that's normal.


Thanks Levente. As you can see, I am a totally newbie with this stuff :(

Ok, this time I cannot be tester.
 

Levente


someone know how can I set the username and password so that to use
NetNameResolver?

Sorry, I tried to test it ;)

Mariano

On Thu, Jan 28, 2010 at 6:38 PM, Stéphane Ducasse <[hidden email]
wrote:

Really thanks for all your energy on that.
I have some administrative taks to do now but I will give a try just after.

On Jan 28, 2010, at 6:06 PM, Miguel Enrique Cobá Martinez wrote:


From Socket class >> initializeNetwork:

     "Initialize the network drivers and the NetNameResolver. Do nothing
if
the network is already initialized."
     "Note: The network must be re-initialized every time Squeak starts
up,
so applications that persist across snapshots should be prepared to
re-initialize the network as needed. Such applications should call
'Socket initializeNetwork' before every network transaction. "

     NetNameResolver initializeNetwork

This explains why the initializeNetwork must be called *before* every
network transaction. Between image restarts the network isn't guaranteed
to remain.

I propose to create a new preference (I know that they are banned but we
need a workaround for 1.0 release) and then each user can, without
modify the NetNameResolver class >>initializeNetwork, change the setting
to the value that works for him/her.

First evaluate:

Preferences addPreference: #useOldNetwork categories:
#(general network)
  default: false balloonHelp: 'Enable/disable the use of the old
network code in making network connections. You need to save and restart
the image to this preference to take effect'
  projectLocal: false changeInformee: nil changeSelector: nil.

to create the preference in a PharoCore 10508 image.

Then load

Network-Kernel-MiguelCoba.22

from PharoInbox.

Pay attention that when you change the preference, it is not refected
immediately. You need to:

1. Open the image with the wrong value of the Preference
2. Change the preference
Preferences enable: #useOldNetwork

 or

Preferences disable: #useOldNetwork
3. Save the image
4. Restart the saved image
5. Evaluate:
NetNameResolver initializeNetwork

or some way use the network (open a monticello browser for example, so
that initializeNetwork is called)

6. Test that the preference is being used:

NetNameResolver useOldNetwork -> value of preference

7. Test that resolves correctly an address:

NetNameResolver addressForName: 'www.yahoo.com' ->
209.131.36.158(f1.www.vip.sp1.yahoo.com),0(0)

8. Save the new image, now with the new preference.

I added this workaround as a fix to issue 1884 and changed status to
fixed.

Can you give it a try please and if so, generate a new image for
PharoCore?

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


_______________________________________________
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: UseOldNetwork possible workaround Was: Re: Bug in NetNameResolver on PharoCore 10508?

Miguel Cobá
El jue, 28-01-2010 a las 21:28 +0100, Mariano Martinez Peck escribió:

>
>
> 2010/1/28 Levente Uzonyi <[hidden email]>
>         On Thu, 28 Jan 2010, Mariano Martinez Peck wrote:
>        
>                 Thanks Miguel. I tried but here in the residence I
>                 have a proxy to with user
>                 and password. To use Monticello or whatever, I always
>                 need to evaluate this:
>                
>                 HTTPSocket useProxyServerNamed: '10.100.1.4' port:
>                 9090
>                 proxyUser: 'XXX' password: 'YYY'
>                
>                 or
>                
>                 HTTPSocket proxyUser: 'XXX' password: 'YYY'.
>                
>                
>                 The problem is that with NetNameResolver  I cannot get
>                 trough the proxy. Do
>        
>        
>         If you only have an HTTP proxy, DNS won't work (but you don't
>         really need that, because the proxy will resolve the domain
>         names). So that's normal.
>        
>
> Thanks Levente. As you can see, I am a totally newbie with this
> stuff :(
>
> Ok, this time I cannot be tester.

No hay problema. :)

Saludos

>  
>  
>        
>         Levente
>        
>        
>        
>                 someone know how can I set the username and password
>                 so that to use
>                 NetNameResolver?
>                
>                 Sorry, I tried to test it ;)
>                
>                 Mariano
>                
>                 On Thu, Jan 28, 2010 at 6:38 PM, Stéphane Ducasse
>                 <[hidden email]
>                         wrote:
>                
>                         Really thanks for all your energy on that.
>                         I have some administrative taks to do now but
>                         I will give a try just after.
>                        
>                         On Jan 28, 2010, at 6:06 PM, Miguel Enrique
>                         Cobá Martinez wrote:
>                        
>                                
>                                         >From Socket class >>
>                                         initializeNetwork:
>                                
>                                      "Initialize the network drivers
>                                 and the NetNameResolver. Do nothing
>                         if
>                                 the network is already initialized."
>                                      "Note: The network must be
>                                 re-initialized every time Squeak
>                                 starts
>                         up,
>                                 so applications that persist across
>                                 snapshots should be prepared to
>                                 re-initialize the network as needed.
>                                 Such applications should call
>                                 'Socket initializeNetwork' before
>                                 every network transaction. "
>                                
>                                      NetNameResolver initializeNetwork
>                                
>                                 This explains why the
>                                 initializeNetwork must be called
>                                 *before* every
>                                 network transaction. Between image
>                                 restarts the network isn't guaranteed
>                                 to remain.
>                                
>                                 I propose to create a new preference
>                                 (I know that they are banned but we
>                                 need a workaround for 1.0 release) and
>                                 then each user can, without
>                                 modify the NetNameResolver class
>                                 >>initializeNetwork, change the
>                                 setting
>                                 to the value that works for him/her.
>                                
>                                 First evaluate:
>                                
>                                 Preferences addPreference:
>                                 #useOldNetwork categories:
>                                 #(general network)
>                                   default: false balloonHelp:
>                                 'Enable/disable the use of the old
>                                 network code in making network
>                                 connections. You need to save and
>                                 restart
>                                 the image to this preference to take
>                                 effect'
>                                   projectLocal: false changeInformee:
>                                 nil changeSelector: nil.
>                                
>                                 to create the preference in a
>                                 PharoCore 10508 image.
>                                
>                                 Then load
>                                
>                                 Network-Kernel-MiguelCoba.22
>                                
>                                 from PharoInbox.
>                                
>                                 Pay attention that when you change the
>                                 preference, it is not refected
>                                 immediately. You need to:
>                                
>                                 1. Open the image with the wrong value
>                                 of the Preference
>                                 2. Change the preference
>                                 Preferences enable: #useOldNetwork
>                                
>                                  or
>                                
>                                 Preferences disable: #useOldNetwork
>                                 3. Save the image
>                                 4. Restart the saved image
>                                 5. Evaluate:
>                                 NetNameResolver initializeNetwork
>                                
>                                 or some way use the network (open a
>                                 monticello browser for example, so
>                                 that initializeNetwork is called)
>                                
>                                 6. Test that the preference is being
>                                 used:
>                                
>                                 NetNameResolver useOldNetwork -> value
>                                 of preference
>                                
>                                 7. Test that resolves correctly an
>                                 address:
>                                
>                                 NetNameResolver addressForName:
>                                 'www.yahoo.com' ->
>                                 209.131.36.158(f1.www.vip.sp1.yahoo.com),0(0)
>                                
>                                 8. Save the new image, now with the
>                                 new preference.
>                                
>                                 I added this workaround as a fix to
>                                 issue 1884 and changed status to
>                                 fixed.
>                                
>                                 Can you give it a try please and if
>                                 so, generate a new image for
>                                 PharoCore?
>                                
>                                 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
>                        
>        
>         _______________________________________________
>         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

--
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: Bug in NetNameResolver on PharoCore 10508?

johnmci
In reply to this post by Stéphane Ducasse
Some of this is all related to

http://bugs.squeak.org/view.php?id=7392

However there is no expectations than any unix socket support code fixes will be forthcoming this year, or next?


On 2010-01-28, at 8:50 AM, Stéphane Ducasse wrote:

> +1
>

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





_______________________________________________
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: Bug in NetNameResolver on PharoCore 10508?

Adrian Lienhard
Do I understand correctly?: ipv6 issues are a VM problem, hence not directly related to Pharo. But #useOldNetwork does not work as advertised in new network implementation because it still uses ipv6 code/primitives.

Hence, should we just roll back the network changes and use the old code as in Squeak 3.9, which, as far as I can tell, works well?

Cheers,
Adrian

On Jan 28, 2010, at 22:52 , John M McIntosh wrote:

> Some of this is all related to
>
> http://bugs.squeak.org/view.php?id=7392
>
> However there is no expectations than any unix socket support code fixes will be forthcoming this year, or next?
>
>
> On 2010-01-28, at 8:50 AM, Stéphane Ducasse wrote:
>
>> +1
>>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>
> _______________________________________________
> 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: Bug in NetNameResolver on PharoCore 10508?

Michael Rueger-6
On 1/29/2010 1:08 PM, Adrian Lienhard wrote:
> Do I understand correctly?: ipv6 issues are a VM problem, hence not
> directly related to Pharo. But #useOldNetwork does not work as
> advertised in new network implementation because it still uses ipv6
> code/primitives.
>
> Hence, should we just roll back the network changes and use the old
> code as in Squeak 3.9, which, as far as I can tell, works well?


Apologies for coming in a bit late into the discussion.

The new network plugin/code was orignally done by Ian and mangled by
myself (with contributions by Bert and Yoshiki IIRC) to be used in etoys
as OLPC is IPv6 only. So would be worthwhile checking the etoys network
code.

Idea behind getting the code into Pharo was to enable more than the
really outdated and bare bones network access available through the old
network code.
That the new stuff still doesn't work is a shame, but IMHO we should fix
it rather than throwing it out.

Patching the current code to allow use of the old network stuff would
buy us time to fix the new code.

Michael

_______________________________________________
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: Bug in NetNameResolver on PharoCore 10508?

Schwab,Wilhelm K
In reply to this post by Adrian Lienhard
+10.



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Adrian Lienhard
Sent: Friday, January 29, 2010 7:09 AM
To: Pharo-project Development
Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Do I understand correctly?: ipv6 issues are a VM problem, hence not directly related to Pharo. But #useOldNetwork does not work as advertised in new network implementation because it still uses ipv6 code/primitives.

Hence, should we just roll back the network changes and use the old code as in Squeak 3.9, which, as far as I can tell, works well?

Cheers,
Adrian

On Jan 28, 2010, at 22:52 , John M McIntosh wrote:

> Some of this is all related to
>
> http://bugs.squeak.org/view.php?id=7392
>
> However there is no expectations than any unix socket support code fixes will be forthcoming this year, or next?
>
>
> On 2010-01-28, at 8:50 AM, Stéphane Ducasse wrote:
>
>> +1
>>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  
> http://www.smalltalkconsulting.com
> ======================================================================
> =====
>
>
>
>
>
> _______________________________________________
> 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: Bug in NetNameResolver on PharoCore 10508?

Schwab,Wilhelm K
In reply to this post by Michael Rueger-6
I for one never said we should throw out the new network code.  But, we've been living in collective denial trying to reduce it to one defect when it is actually more complicated than that.

Having cited the over-use of inheritance of the Squeak image as a source of various problems, I will add that inheritance *should* be used in NetNameResolver - specifically, we should group the ipv4 and ipv6 primitive sends into protocol-specific subclasses.  Errors that are now weird-looking primitive failures will suddenly become DNU errors with an obvious cause.

We should further send SocketAddress to its reward and make any required changes to use an aspect-based address that can lazily help with name resolution, and does not drag the port number into the address.  The socket primitives will have to change at the same time (I think).

IMHO, the only quick fix is to go back to known working network code, at which point we can plan for IPv6 in a future milestone.  I urge the next attempt be based on an improved design, hopefully one that will allow OpenSSL sockets along with the usual suspects.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Rueger
Sent: Friday, January 29, 2010 7:23 AM
To: [hidden email]
Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

On 1/29/2010 1:08 PM, Adrian Lienhard wrote:
> Do I understand correctly?: ipv6 issues are a VM problem, hence not
> directly related to Pharo. But #useOldNetwork does not work as
> advertised in new network implementation because it still uses ipv6
> code/primitives.
>
> Hence, should we just roll back the network changes and use the old
> code as in Squeak 3.9, which, as far as I can tell, works well?


Apologies for coming in a bit late into the discussion.

The new network plugin/code was orignally done by Ian and mangled by myself (with contributions by Bert and Yoshiki IIRC) to be used in etoys as OLPC is IPv6 only. So would be worthwhile checking the etoys network code.

Idea behind getting the code into Pharo was to enable more than the really outdated and bare bones network access available through the old network code.
That the new stuff still doesn't work is a shame, but IMHO we should fix it rather than throwing it out.

Patching the current code to allow use of the old network stuff would buy us time to fix the new code.

Michael

_______________________________________________
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: Bug in NetNameResolver on PharoCore 10508?

Marcus Denker-4

On Jan 29, 2010, at 3:20 PM, Schwab,Wilhelm K wrote:

> I for one never said we should throw out the new network code.  But, we've been living in collective denial trying to reduce it to one defect when it is actually more complicated than that.
>
> Having cited the over-use of inheritance of the Squeak image as a source of various problems, I will add that inheritance *should* be used in NetNameResolver - specifically, we should group the ipv4 and ipv6 primitive sends into protocol-specific subclasses.  Errors that are now weird-looking primitive failures will suddenly become DNU errors with an obvious cause.
>
> We should further send SocketAddress to its reward and make any required changes to use an aspect-based address that can lazily help with name resolution, and does not drag the port number into the address.  The socket primitives will have to change at the same time (I think).
>
> IMHO, the only quick fix is to go back to known working network code, at which point we can plan for IPv6 in a future milestone.  I urge the next attempt be based on an improved design, hopefully one that will allow OpenSSL sockets along with the usual suspects.

I vote for exploring if libevent would be a possibility.... this is the library that the TOR project did for their strange needs, it seems it was picked up by google for Chromium and Memcached.

http://google-opensource.blogspot.com/2010/01/libevent-20x-like-libevent-14x-only.html

        Libevent 2.0.x is the new version of Libevent from the Tor Project. Libevent is a software library whose purpose is to provide consistent
        fast interfaces to various operating systems' mutually incompatible fast networking facilities.

No idea if it's useful as the base-layer of a new networking stack, but at least worth a look.

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
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: Bug in NetNameResolver on PharoCore 10508?

Stéphane Ducasse
In reply to this post by Michael Rueger-6
Mike

do you have some cycles to help here?

Stef

On Jan 29, 2010, at 1:23 PM, Michael Rueger wrote:

> On 1/29/2010 1:08 PM, Adrian Lienhard wrote:
>> Do I understand correctly?: ipv6 issues are a VM problem, hence not
>> directly related to Pharo. But #useOldNetwork does not work as
>> advertised in new network implementation because it still uses ipv6
>> code/primitives.
>>
>> Hence, should we just roll back the network changes and use the old
>> code as in Squeak 3.9, which, as far as I can tell, works well?
>
>
> Apologies for coming in a bit late into the discussion.
>
> The new network plugin/code was orignally done by Ian and mangled by
> myself (with contributions by Bert and Yoshiki IIRC) to be used in etoys
> as OLPC is IPv6 only. So would be worthwhile checking the etoys network
> code.
>
> Idea behind getting the code into Pharo was to enable more than the
> really outdated and bare bones network access available through the old
> network code.
> That the new stuff still doesn't work is a shame, but IMHO we should fix
> it rather than throwing it out.
>
> Patching the current code to allow use of the old network stuff would
> buy us time to fix the new code.
>
> Michael
>
> _______________________________________________
> 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: Bug in NetNameResolver on PharoCore 10508?

Michael Rueger-6
On 1/29/2010 6:28 PM, Stéphane Ducasse wrote:
> Mike
>
> do you have some cycles to help here?

let me see what I can come up with :-)

Michael

_______________________________________________
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: Bug in NetNameResolver on PharoCore 10508?

Stéphane Ducasse
thanks

I need to hack something simple to destress from proposal writing.
But I have no clue about network
Stef

On Jan 29, 2010, at 6:48 PM, Michael Rueger wrote:

> On 1/29/2010 6:28 PM, Stéphane Ducasse wrote:
>> Mike
>>
>> do you have some cycles to help here?
>
> let me see what I can come up with :-)
>
> Michael
>
> _______________________________________________
> 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: Bug in NetNameResolver on PharoCore 10508?

hernan.wilkinson
In reply to this post by Miguel Cobá
The changed you suggested worked on my machine, mac os X and also on a Debian.

Hernan.

2010/1/28 Miguel Enrique Cobá Martinez <[hidden email]>
El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribió:
> I think you are correct about that being a bad change, but there is more wrong than just that.  There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork.  Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true.  I make that change in #useOldNetwork rather than #initialize.
>
> Bill


Yes, I know that the code is very difficult to understand, mainly
because of the primitives. They brake the understanding you have so far
when you have to switch to c code with a lot of pointers/structs/string
buffers.

The problem here is that, now it is impossible to change the networks
subsystem of Pharo (or squeak). As Mariano said, we *need* to release
1.0 and this bug can be a show stopper.

Also, with due respect to the original coders of the network subsystem,
the code is really convoluted (I know that networking isn't simple), at
least to understand the fully implication of a "simple" change like
this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6,
primitives and smalltalk code. So I think that is difficult to have
someone with the enough knowledge to change the code so that it works
for now. But that is how things are now. Maybe our own ignorance of the
code is what negates us a fix, but we need to left that apart and work a
solution for the *particular* problem in hand. For 1.1 we can discuss
new implementation if that is required.

As Adrian said, there are users that need useOldNetwork true and some
others that need useOldNetwork to false. The problem is that we don't
fully understand the consequences of both changes.

So, people, we need your help. Those who are most familiar with the
network code, please, please, take a look and suggest a solution for the
1.0 release. *No* full rewrites, no throw code, no blaming, just a
working workaround for this.

Regards

Miguel Coba

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in NetNameResolver on PharoCore 10508?

Schwab,Wilhelm K
The OS/vm is part of it; behavior also depends on whether the network is configured for ipv6, and perhaps whether or not it is done correctly.  It gets complicated in a hurry.

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Hernan Wilkinson [[hidden email]]
Sent: Friday, January 29, 2010 5:27 PM
To: [hidden email]
Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

The changed you suggested worked on my machine, mac os X and also on a Debian.

Hernan.

2010/1/28 Miguel Enrique Cobá Martinez <[hidden email]<mailto:[hidden email]>>
El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribió:
> I think you are correct about that being a bad change, but there is more wrong than just that.  There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork.  Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true.  I make that change in #useOldNetwork rather than #initialize.
>
> Bill


Yes, I know that the code is very difficult to understand, mainly
because of the primitives. They brake the understanding you have so far
when you have to switch to c code with a lot of pointers/structs/string
buffers.

The problem here is that, now it is impossible to change the networks
subsystem of Pharo (or squeak). As Mariano said, we *need* to release
1.0 and this bug can be a show stopper.

Also, with due respect to the original coders of the network subsystem,
the code is really convoluted (I know that networking isn't simple), at
least to understand the fully implication of a "simple" change like
this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6,
primitives and smalltalk code. So I think that is difficult to have
someone with the enough knowledge to change the code so that it works
for now. But that is how things are now. Maybe our own ignorance of the
code is what negates us a fix, but we need to left that apart and work a
solution for the *particular* problem in hand. For 1.1 we can discuss
new implementation if that is required.

As Adrian said, there are users that need useOldNetwork true and some
others that need useOldNetwork to false. The problem is that we don't
fully understand the consequences of both changes.

So, people, we need your help. Those who are most familiar with the
network code, please, please, take a look and suggest a solution for the
1.0 release. *No* full rewrites, no throw code, no blaming, just a
working workaround for this.

Regards

Miguel Coba

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


_______________________________________________
Pharo-project mailing list
[hidden email]<mailto:[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: Bug in NetNameResolver on PharoCore 10508?

Miguel Cobá
In reply to this post by hernan.wilkinson
El vie, 29-01-2010 a las 19:27 -0300, Hernan Wilkinson escribió:
> The changed you suggested worked on my machine, mac os X and also on a
> Debian.
>

Thank you for testing. I have only a Debian Squeeze machine and only
tested there. But is good to know that works also in MacOS X. I am
installing Windows 7 inside virtualbox to test in windows.

Cheers

>
> Hernan.
>
> 2010/1/28 Miguel Enrique Cobá Martinez <[hidden email]>
>         El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K
>         escribió:
>         > I think you are correct about that being a bad change, but
>         there is more wrong than just that.  There are IPv6-specific
>         calls that are not protected by subsequent tests on
>         #useOldNetwork.  Further, the IPv6 code does not work
>         correctly, so many of us appear to need to override
>         #useOldNetwork to always return true.  I make that change in
>         #useOldNetwork rather than #initialize.
>         >
>         > Bill
>        
>        
>        
>         Yes, I know that the code is very difficult to understand,
>         mainly
>         because of the primitives. They brake the understanding you
>         have so far
>         when you have to switch to c code with a lot of
>         pointers/structs/string
>         buffers.
>        
>         The problem here is that, now it is impossible to change the
>         networks
>         subsystem of Pharo (or squeak). As Mariano said, we *need* to
>         release
>         1.0 and this bug can be a show stopper.
>        
>         Also, with due respect to the original coders of the network
>         subsystem,
>         the code is really convoluted (I know that networking isn't
>         simple), at
>         least to understand the fully implication of a "simple" change
>         like
>         this. It is not a well factored code. It mixes GUI prompts,
>         IPv4, IPv6,
>         primitives and smalltalk code. So I think that is difficult to
>         have
>         someone with the enough knowledge to change the code so that
>         it works
>         for now. But that is how things are now. Maybe our own
>         ignorance of the
>         code is what negates us a fix, but we need to left that apart
>         and work a
>         solution for the *particular* problem in hand. For 1.1 we can
>         discuss
>         new implementation if that is required.
>        
>         As Adrian said, there are users that need useOldNetwork true
>         and some
>         others that need useOldNetwork to false. The problem is that
>         we don't
>         fully understand the consequences of both changes.
>        
>         So, people, we need your help. Those who are most familiar
>         with the
>         network code, please, please, take a look and suggest a
>         solution for the
>         1.0 release. *No* full rewrites, no throw code, no blaming,
>         just a
>         working workaround for this.
>        
>         Regards
>        
>         Miguel Coba
>        
>         --
>        
>         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

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


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