- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [Vm-dev] Fwd: Show stopper network bug on Windows

by Igor Stasenko

All, who interested in this, please continue this topic on VM-dev list. Because Andreas is maintainer of windoze VM, and no one knows better than he is of what is working or not and why. ---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: 2009/7/23 Subject: Re: [Vm-dev] Fwd: [Pharo-project] Show stopper network bug on Windows To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> Igor Stasenko wrote: > > Hello guys, those, who not subscribed to the Pharo list. > > I think you should read this: > Â http://code.google.com/p/pharo/issues/detail?id=961 > > since it seems there are some networking problems with Win32 VM. None of these are Windows VM issues. The problem referred to above is simply that someone was using a year-old 3.10.2 VM and tried to call IPv6 primitives (the debug log shows that clearly). The IPv6 prims are not available in these old VMs. The discussion below is similarly confused. The Windows VM does return fully qualified names if your network environment is set up properly. Usually, the domain name is set by DHCP, but you can set it manually in the advanced network settings (on XP it's under network, properties, TCP/IP, advanced, append dns suffixes; Vista will surely differ). Cheers, Â - Andreas -- Best regards, Igor Stasenko AKA sig.

July 22, 2009

Re: [Pharo-project] Author class

by Miguel CobÃ¡

On Wed, Jul 22, 2009 at 5:20 PM, Miguel CobÃ¡<miguel.coba(a)gmail.com> wrote: > On Wed, Jul 22, 2009 at 4:32 PM, StÃ©phane > Ducasse<stephane.ducasse(a)inria.fr> wrote: >>> >>> Yes but I mean, in a clean core image, on first method save it asks >>> for the initials, >>> this is stored on the initials inst var of the singleton Author. >>> >>> But on the World Menu, the set author name, it stores (in a >>> firstname.lastname format) the >>> value entered in the name inst var >>> >>> So, setting one, doesn't set the other. >>> Also, the messages are different for each one (rightly, because are >>> different things) but I >>> want to know what is the inteded behavior from now on to trying to do >>> the changes. >> >> Yes this is the mess. >> Can you propose a nice solution? > > Ok, this is the proposal. > > The Author class will use only the name inst var and related methods. > The initials related are to be unused and later droped in a subsecuent release. > > All the calls to initials methods will be replaced by names methods. > > The format for the name will be free, and suggested by the prompt message to > > firstname.lastname > > but not enforced. > > It will not allow spaces, just letters and periods in places of spaces e.g. > > Miguel CobÃ¡ -> miguel.coba > John The Hacker -> john.the.hacker > Peter O'Toole -> peter.otoole or maybe peter.o.toole > > This period in place of space can be discussed because monticello > replaces periods for "_". > Maybe 'firstname_lastname' should be suggested in the prompt. > > Every package not in core that use the initial methods should be > allowed to use the deprecated > initials methods but strongly urged to change to the names methods. > > At least in core, the initials should not be used anymore. > > What do you think? > > Miguel CobÃ¡ > > Something easier would be to write the same to initials and name no matter what method was called, this would be less disruptive to the image but it will also have to modify the prompt messages to not mention initials but name in all messages. I, personally, vote for the complete delete of initials code mentioned before. Miguel CobÃ¡ >> >>> Is the user only asked for name (forcing a format like >>> firstname.lastname) and the initials >>> are calculated accordingly? >> >> would be good but some people on ss have funky initials because theirs >> were taken. >> This is why initials does not scale. >> >>> Are the initials doomed to disappear, and the only interface will be >>> the name (and possibly the >>> email and other fields mentioned) to identify a person? This means to >>> modify all the senders to >>> initial methods and point them to name methods. With the time, the >>> initials inst var will be droped >>> from the Author class. >> >> I think so. >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

July 22, 2009

Re: [Pharo-project] Author class

by Miguel CobÃ¡

On Wed, Jul 22, 2009 at 5:58 PM, Douglas Brebner<squeaklists(a)fang.demon.co.uk> wrote: > Miguel CobÃ¡ wrote: >> On Wed, Jul 22, 2009 at 2:53 PM, StÃ©phane >> Ducasse<stephane.ducasse(a)inria.fr> wrote: >>>> I can unify all the message sends to Author in the core image, also I >>>> can unify the initials and name usage, but >>>> >>> It would be nice :) >>> The prompt should ask for firstname.lastname and not initials :) >>> >>> >> >> So I can replace all the prompts to initials for name in the format you mention. >> >> Will this format be the prefered/oficial one? >> Will other formats be allowed? Maybe asking for firstname and then for >> lastname and >> then inside Author concatenating in a firstname.lastname. >> >> What happens with someone with two firstnames and lastnames, like me: >> >> Miguel Enrique CobÃ¡ MartÃnez >> >> Firstname: Miguel Enrique >> Lastname: CobÃ¡ MartÃnez >> >> yes it is an bad example as I would write: >> >> Firstname: Miguel >> Lastname: CobÃ¡ >> >> What about spaces? >> > > Spaces aren't avoidable since some names have them e.g. "von Braun". > Other things to consider are some cultures (like japanese) write names > lastname, firstname and others have non-letter chars in their names e.g. > irish names can have apostrophies like "O'Brien" and double barrelled > names can have dashes. > > The best way to do it might be to just have a field for you to input > your name in your preferred form since proper international name > handling is complicated. Yes, I know, my lastname has an acute accent. So then we can, in the prompt, suggest to not use spaces and to write an ascii aproximation (until full unicode input it is enabled in the image) of his prefered name string, e.g. miguel.coba MiguelCoba miguelcoba MiguelVonCoba MiguelOBrian GoeranKrampe GoranKrampe YoshikiOshima etc Cheers, Miguel CobÃ¡ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 22, 2009

Re: [Pharo-project] Author class

by Douglas Brebner

Miguel CobÃ¡ wrote: > On Wed, Jul 22, 2009 at 2:53 PM, StÃ©phane > Ducasse<stephane.ducasse(a)inria.fr> wrote: >>> I can unify all the message sends to Author in the core image, also I >>> can unify the initials and name usage, but >>> >> It would be nice :) >> The prompt should ask for firstname.lastname and not initials :) >> >> > > So I can replace all the prompts to initials for name in the format you mention. > > Will this format be the prefered/oficial one? > Will other formats be allowed? Maybe asking for firstname and then for > lastname and > then inside Author concatenating in a firstname.lastname. > > What happens with someone with two firstnames and lastnames, like me: > > Miguel Enrique CobÃ¡ MartÃnez > > Firstname: Miguel Enrique > Lastname: CobÃ¡ MartÃnez > > yes it is an bad example as I would write: > > Firstname: Miguel > Lastname: CobÃ¡ > > What about spaces? > Spaces aren't avoidable since some names have them e.g. "von Braun". Other things to consider are some cultures (like japanese) write names lastname, firstname and others have non-letter chars in their names e.g. irish names can have apostrophies like "O'Brien" and double barrelled names can have dashes. The best way to do it might be to just have a field for you to input your name in your preferred form since proper international name handling is complicated.

July 22, 2009

Re: [Pharo-project] about

by Igor Stasenko

2009/7/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Juan pointed to me the following CUIS fixes that could interest us. > Now I feel not able to check that. > Is there somebody good (SIG for example :)) that could spend some time > on that? > Stef, i wish i could have more than a single life on that :) My current list of employment: - work on paid project(s) - work on own small project (will announce soon) - finish work on VM+Image Process Scheduling refactoring - work on DeltaStreams with Goran - continue work on host windows refactoring - continue work on Moebuis project .. there could be more , which i missed unintentionally. so, i don't want to give any empty promises, that i will take a look at it in nearest time. :( > Stef > > > Kernel: Semaphores, Delays, Processes, WeakReferences > ------------------------------------------------------------------------- > 0101-SafeDelay-2-ar.cs > 0102-DelayTweaks-ar.cs > 0103-DelayStartup-jmv.cs > 0104-SemaCritical-ar.cs > 0130-CreateSemaphoreTest-jmv.1.cs > 0131-DelayCleanup-ar.1.cs > 0132-AtomicProcessSuspend-ar.1.cs > 0133-ProcessTerminateFix-ar.2.cs > 0134-DelayWaitTimeout-ar.2.cs > 0135-SignalExceptionFix-ar.1.cs > 0136-assertFix-jmv.1.cs > 0137-SemaTests-ar.cs > 0173-offList-jmv.1.cs > 0187-DelayWaitTimeout-ar.3.cs > 0192-WeakMessageSendFixPart1-jmv-M7352.cs > 0193-WeakMessageSendFixPart2-jmv-M7352.1.cs > 0207-AvoidCreatingDelays-jmv.1.cs > 0212-ForkSenders-jmv.1.cs > 0213-ForkAnswersNil-jmv.5.cs > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 22, 2009

Re: [Pharo-project] Author class

by Miguel CobÃ¡

On Wed, Jul 22, 2009 at 4:32 PM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: >> >> Yes but I mean, in a clean core image, on first method save it asks >> for the initials, >> this is stored on the initials inst var of the singleton Author. >> >> But on the World Menu, the set author name, it stores (in a >> firstname.lastname format) the >> value entered in the name inst var >> >> So, setting one, doesn't set the other. >> Also, the messages are different for each one (rightly, because are >> different things) but I >> want to know what is the inteded behavior from now on to trying to do >> the changes. > > Yes this is the mess. > Can you propose a nice solution? Ok, this is the proposal. The Author class will use only the name inst var and related methods. The initials related are to be unused and later droped in a subsecuent release. All the calls to initials methods will be replaced by names methods. The format for the name will be free, and suggested by the prompt message to firstname.lastname but not enforced. It will not allow spaces, just letters and periods in places of spaces e.g. Miguel CobÃ¡ -> miguel.coba John The Hacker -> john.the.hacker Peter O'Toole -> peter.otoole or maybe peter.o.toole This period in place of space can be discussed because monticello replaces periods for "_". Maybe 'firstname_lastname' should be suggested in the prompt. Every package not in core that use the initial methods should be allowed to use the deprecated initials methods but strongly urged to change to the names methods. At least in core, the initials should not be used anymore. What do you think? Miguel CobÃ¡ > >> Is the user only asked for name (forcing a format like >> firstname.lastname) and the initials >> are calculated accordingly? > > would be good but some people on ss have funky initials because theirs > were taken. > This is why initials does not scale. > >> Are the initials doomed to disappear, and the only interface will be >> the name (and possibly the >> email and other fields mentioned) to identify a person? This means to >> modify all the senders to >> initial methods and point them to name methods. With the time, the >> initials inst var will be droped >> from the Author class. > > I think so. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 22, 2009

[Pharo-project] Updating 10387 failed

by Nicolas Cellier

This is what I get during the update: ThirtyTwoBitRegister doesNotUnderstand: #load: This is triggered by: MD5NonPrimitive>>initialize "MD5 initialize" "Obscure fact: those magic hex numbers that are hard to type in correctly are actually the result of a simple trigonometric function and are therefore easier to compute than proofread. Laziness is sometimes a virtue." | c | c _ 2 raisedTo: 32. SinTable _ Array new: 64. 1 to: 64 do: [ :i | SinTable at: i put: (ThirtyTwoBitRegister new load: (c * i sin abs) truncated)]. SNIP... Is this related to load order or something? Also mind the previously banned underscores... Nicolas

July 22, 2009

Re: [Pharo-project] Author class

by Miguel CobÃ¡

Also, check this bug in mantis http://bugs.squeak.org/view.php?id=6993 It can be added to the author class also and unify them in a single place. On Wed, Jul 22, 2009 at 4:35 PM, Miguel CobÃ¡<miguel.coba(a)gmail.com> wrote: > On Wed, Jul 22, 2009 at 2:53 PM, StÃ©phane > Ducasse<stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> What is the goal with the Author class? I can see that the Utilities >>> methods that used to be use to set >>> author name and initials are being replaced with calls to Author. >>> Also, they are deprecated in Utilities. >>> Questions: >>> >>> Author has name and initials, what will be the intended use of them? >> >> We should not use initials. > > This means that all the methods referencing initials should be > replaced with calls > to equivalent name methods? > >> We should not use Utilities in the future. >> >>> By previous mails in the list I remember >>> that Pharo doesn't want to use initials (like mcm, lr, avi) but full >>> name as hinted by the message prompt in >>> the Author requestName. But then initials will have exactly the same >>> that name in the author class? >> >> It should be cleaned but nobody took the time. >> > > I can do, but I need more directions > >>> I can unify all the message sends to Author in the core image, also I >>> can unify the initials and name usage, but >> >> It would be nice :) >> The prompt should ask for firstname.lastname and not initials :) >> > > So I can replace all the prompts to initials for name in the format you mention. > > Will this format be the prefered/oficial one? > Will other formats be allowed? Maybe asking for firstname and then for > lastname and > then inside Author concatenating in a firstname.lastname. > > What happens with someone with two firstnames and lastnames, like me: > > Miguel Enrique CobÃ¡ MartÃnez > > Firstname: Miguel Enrique > Lastname: CobÃ¡ MartÃnez > > yes it is an bad example as I would write: > > Firstname: Miguel > Lastname: CobÃ¡ > > What about spaces? > >>> I need to know the intended goal for this class. >>> >>> What is the goal? >> >> To represent metadata of the author. >> Probably having initial and password for monticello/ squeaksource >> makes sense. >> >> > > What is the reason to store the password, to automate login to squeaksource, or > something like that? > > Thanks, > Miguel CobÃ¡ >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

July 22, 2009

[Pharo-project] about

by StÃ©phane Ducasse

Juan pointed to me the following CUIS fixes that could interest us. Now I feel not able to check that. Is there somebody good (SIG for example :)) that could spend some time on that? Stef Kernel: Semaphores, Delays, Processes, WeakReferences ------------------------------------------------------------------------- 0101-SafeDelay-2-ar.cs 0102-DelayTweaks-ar.cs 0103-DelayStartup-jmv.cs 0104-SemaCritical-ar.cs 0130-CreateSemaphoreTest-jmv.1.cs 0131-DelayCleanup-ar.1.cs 0132-AtomicProcessSuspend-ar.1.cs 0133-ProcessTerminateFix-ar.2.cs 0134-DelayWaitTimeout-ar.2.cs 0135-SignalExceptionFix-ar.1.cs 0136-assertFix-jmv.1.cs 0137-SemaTests-ar.cs 0173-offList-jmv.1.cs 0187-DelayWaitTimeout-ar.3.cs 0192-WeakMessageSendFixPart1-jmv-M7352.cs 0193-WeakMessageSendFixPart2-jmv-M7352.1.cs 0207-AvoidCreatingDelays-jmv.1.cs 0212-ForkSenders-jmv.1.cs 0213-ForkAnswersNil-jmv.5.cs

July 22, 2009

Re: [Pharo-project] Author class

by Miguel CobÃ¡

On Wed, Jul 22, 2009 at 2:53 PM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: >> >> >> What is the goal with the Author class? I can see that the Utilities >> methods that used to be use to set >> author name and initials are being replaced with calls to Author. >> Also, they are deprecated in Utilities. >> Questions: >> >> Author has name and initials, what will be the intended use of them? > > We should not use initials. This means that all the methods referencing initials should be replaced with calls to equivalent name methods? > We should not use Utilities in the future. > >> By previous mails in the list I remember >> that Pharo doesn't want to use initials (like mcm, lr, avi) but full >> name as hinted by the message prompt in >> the Author requestName. But then initials will have exactly the same >> that name in the author class? > > It should be cleaned but nobody took the time. > I can do, but I need more directions >> I can unify all the message sends to Author in the core image, also I >> can unify the initials and name usage, but > > It would be nice :) > The prompt should ask for firstname.lastname and not initials :) > So I can replace all the prompts to initials for name in the format you mention. Will this format be the prefered/oficial one? Will other formats be allowed? Maybe asking for firstname and then for lastname and then inside Author concatenating in a firstname.lastname. What happens with someone with two firstnames and lastnames, like me: Miguel Enrique CobÃ¡ MartÃnez Firstname: Miguel Enrique Lastname: CobÃ¡ MartÃnez yes it is an bad example as I would write: Firstname: Miguel Lastname: CobÃ¡ What about spaces? >> I need to know the intended goal for this class. >> >> What is the goal? > > To represent metadata of the author. > Probably having initial and password for monticello/ squeaksource > makes sense. > > What is the reason to store the password, to automate login to squeaksource, or something like that? Thanks, Miguel CobÃ¡ > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 22, 2009