Bug in NetNameResolver on PharoCore 10508?

>> 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

>
>> 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

> 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

>
>
> 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

> 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

> 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

> 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

> 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

>
> 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