January 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Question about alias in traits

by Hernan Wilkinson

thanks, I don't know why I thought that the alias was a rename too (maybe the name suggested me that...) I think that having a "rename operator" that acts on the trait being composed in messages send to self would help in most of the cases, but as you say, it is not possible to take care of all the cases. Thanks! Hernan. On Thu, Jan 10, 2013 at 4:17 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Jan 10, 2013, at 2:17 PM, Damien Cassou wrote: > > > On Thu, Jan 10, 2013 at 1:21 PM, Hernan Wilkinson > > <hernan.wilkinson(a)10pines.com> wrote: > >> Was my interpretation of Alias incorrect? or is the current > implementation > >> of alias incorrect? (maybe due to some implementation problems?) > > > > @ is an Alias operator, not a Rename operator. That means when you > > alias { #m3 -> #m1 } you get a new name for the same method. So what > > you see is the expected behavior, as defined in the paper. And the > > direction of the arrow makes sense: #m3 -> #m1 is read as "m3 is a new > > name for m1", whereas for a Rename operator, we would probably have > > something like "#m1 -> #m3", i.e., m1 is renamed to m3. In a fully > > dynamic language, a Rename operator would be quite hard to implement I > > guess, IIRC Eiffel has a rename operator. > > Not quite hard. doing it fully and correctly is no possible because you > should distinguish the methods > that should be renamed. > > > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

Jan. 14, 2013

Inria Research Positions Lille

by Marcus Denker

FULL TIME PERMANENT RESEARCH POSITIONS IN LILLE, FRANCE ======================================================= Inria-Lille, RMoD Research Group The RMoD research group invites applications to 3 CR2 an/or CR1 positions in the Inria center of Lille, France. Proficiency in French is not required. CR2 âYoung graduate scientistâ --------------- The CR2 position is the entry level, a junior researcher position. No teaching, permanent position with tenure after a probation period of 12 Months. Requirements: - A PhD - In practice, the competition is very hard and a strong academic CV is needed on a level that requires, besides a very good PhD, at least one to two years of postdoctoral research experience. CR1 âYoung experienced scientistâ ----------------- The CR1 position is for confirmed researchers with experience in research, strong international recognition, and established leading abilities. No teaching, permanent position with tenure after a probation period of 12 Months. Requirements: - A PhD and four years of research experience. - A very strong academic CV. PROFILE ------------- The candidate must have a doctoral degree, a strong background in Computer Science, and internationally significant research achievements in software engineering (particularly software evolution) and/or programming languages. Duties include: -Research (no teaching). -Help manage the RMoD Research group. -Be involved with the self-governance of the Inria Lab and Inria as a whole. -Guide PhD students (and therefore get a French habilitation to be able to formally supervise PhD students). -Help acquire additional funds for PhD students, Postdocs and Engineers. -Transfer research results to the real world. MISSION -------- Join one of our two lines of research: Tools for Software Maintenance or New Programming Language Constructs for Software Evolution. THE REGION ---------- Lille is strategically located in Northern Europe with train connections to Paris (1h), London (1h30) and Brussels (30 min.) The Nord Pas de Calais region is a dynamic area in both industry and research for computer science with companies that are european leaders in their branch. Lille, the capital of northern France is an attractive metropolis of over 1 million inhabitants. Cost of living in Lille is lower than that of very big cities such as Paris and London. THE TEAM -------- RMoD is an Inria research project team. It consists of 6 permant researchers (Inria CR and DR, as well as University Assistant Professors) and Engineers, postdocs and students (Master and PhD). RMoD is an international team with more than 20 members from six countries. LINKS: RMoD: http://rmod.lille.inria.fr INRIA Lille: http://www.inria.fr/lille/ INRIA in General: http://www.inria.fr Lille: - http://en.wikipedia.org/wiki/Lille - http://wikitravel.org/en/Lille APPLICATION ------------ Please contact the head of the research team: Stephane.Ducasse(a)inria.fr or one of the following group members: Nicolas.Anquetil(a)inria.fr, Marcus.Denker(a)inria.fr or Damien.Cassou(a)inria.fr Permanent Link to this Call: http://rmod.lille.inria.fr/web/pier/blog/2013-01-14

Jan. 14, 2013

Problem installing Neptuno

by Frank Church

When I try to install Neptuno in Pharo 1.4 I get the error - 'announcer is already defined in MorphTreeModel' Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfDBXTools'; load. (((Smalltalk at: #ConfigurationOfDBXTools) perform: #project) perform: #version: with: #stable) load: 'Phoseydon'. Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfDBXBrowser'; load. (((Smalltalk at: #ConfigurationOfDBXTools) perform: #project) perform: #version: with: #stable) load: 'Neptuno' . The error happens at the last stage when I am installing Neptuno. The issue appears in the DBXTalk mailing list - http://forum.world.st/Re-Pharo-project-How-to-load-Phoseydon-and-Neptuno-td… -- Frank Church ======================= http://devblog.brahmancreations.com

Jan. 14, 2013

Re: [Pharo-users] #name

by Robert Shiplett

Having the option to use #name proves very useful in the Curl language for tagging objects - usually #clientFirstName #clientLastName etc. prevent any issues ( I rank the "my" of #myName with "this" - for which we already have "self" ! :-) ). Does anyone else find it useful to know that you will be able to tag an object ? Should #name in LookupKey be #keyString ? FileStream #fileName ?? Only Exception uses #tag ?? #nameTag ?? I think that in the base Pharo 1.4 there are no senders of #tag or #tag: so that looks like a nice option But a "name" String should be avoided as an identifier slot for an instance object's identity, right ? On 13 January 2013 05:52, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Jan 13, 2013, at 10:13 AM, Ben Coman wrote: > > > What is the purpose of the #name method in the system? > > It was because in etoy you can give a name to anythingâ¦. I would love to > remove. > > How integral/important is this method and what are the dangers of > overriding it? > On class I guess that it is dangerous > > > I am getting tired of auto creating accessors and getting a #name1 > method due to a clash that I happened to very commonly have 'name' as an > instance variable. I have so far been changing my 'name' instance > variables to 'myName' to avoid the clash because I am not comfortable with > my understanding of how it ties in - but its time I tried harder to > understand. > > Welcome to the club > One day we will address it just that we have not enough fingers and brains. > > > > > cheers -ben > > > > > > >

Jan. 13, 2013

Re: [Pharo-users] #name

by StÃ©phane Ducasse

On Jan 13, 2013, at 10:13 AM, Ben Coman wrote: > What is the purpose of the #name method in the system? It was because in etoy you can give a name to anythingâ¦. I would love to remove. > How integral/important is this method and what are the dangers of overriding it? On class I guess that it is dangerous > I am getting tired of auto creating accessors and getting a #name1 method due to a clash that I happened to very commonly have 'name' as an instance variable. I have so far been changing my 'name' instance variables to 'myName' to avoid the clash because I am not comfortable with my understanding of how it ties in - but its time I tried harder to understand. Welcome to the club One day we will address it just that we have not enough fingers and brains. > > cheers -ben > >

Jan. 13, 2013

Re: [Pharo-users] #name

by Milan Mimica

On 13 January 2013 10:13, Ben Coman <btc(a)openinworld.com> wrote: > What is the purpose of the #name method in the system? > How integral/important is this method and what are the dangers of > overriding it? > On instance side, I think you can override it with no harm. You will have that object's name displayed in Inspector and other places - but that's fine, afterall that is that object's name. -- Milan Mimica http://sparklet.sf.net

Jan. 13, 2013

#name

by Ben Coman

What is the purpose of the #name method in the system? How integral/important is this method and what are the dangers of overriding it? I am getting tired of auto creating accessors and getting a #name1 method due to a clash that I happened to very commonly have 'name' as an instance variable. I have so far been changing my 'name' instance variables to 'myName' to avoid the clash because I am not comfortable with my understanding of how it ties in - but its time I tried harder to understand. cheers -ben

Jan. 13, 2013

Re: [Pharo-users] Change in NativeLinux32>>getGlobalSymbolPointer

by Jesus NuÃ±ez

OK I fixed it. For some reason the session was opened but and I coudn't issue NativeBoost initilize, I just setted the Current variable to nil and the session was reinitialized at the next call to NativeBoost. Cheers, Jesus 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> > Hi Igor, > > Promise the last question today. > > What can be causing that issuing: > > > "NativeBoost forCurrentPlatform callbackCounterAddress. " > > returns "nil" ?. > > > In the trunk 1.8 is OK and it returns "@16r282000" in my case. > > Thanks in advance, > > Jesus > > > 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> > >> Sorry what operation should I do over the new versions in Montincello to >> load them safely?? >> >> >> 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> >> >>> Yes Ok, I got it. The question is that the #value: selector is still >>> there, with the old code. Sorry, I should have check the new code directly >>> in the repository and compare it. >>> >>> Thank you. >>> >>> >>> 2013/1/12 Igor Stasenko <siguctua(a)gmail.com> >>> >>>> On 12 January 2013 19:00, Jesus NuÃ±ez <poissonbreaker(a)gmail.com> wrote: >>>> > BTW I also tried returning with ";yourself" but no luck in the test I >>>> made. >>>> > >>>> > >>>> i dont know what you trying to change there. this code works fine, >>>> because >>>> if it would not, then nothing else would work at all. >>>> >>>> >>>> > 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> >>>> >> >>>> >> Ok, but happens that #value: uses #fieldAt: was inherited from >>>> >> NBExternalStructure, which is no longer in the hierarchy. But I >>>> understand >>>> >> that it will no longer work with the change I made, any idea? >>>> >> >>>> >> >>>> >> Best Regards, >>>> >> >>>> >> Jesus >>>> >> >>>> >> >>>> >> 2013/1/12 Igor Stasenko <siguctua(a)gmail.com> >>>> >>> >>>> >>> No, it should be >>>> >>> NBExternalAddress value: addr >>>> >>> because method should answer an instance of NBExternalAddress >>>> >>> not integer. >>>> >>> >>>> >>> On 12 January 2013 15:25, Jesus NuÃ±ez <poissonbreaker(a)gmail.com> >>>> wrote: >>>> >>> > Sorry. NBExternalAddress new ulongAt: adress >>>> >>> > >>>> >>> > >>>> >>> > 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> >>>> >>> >> >>>> >>> >> I have made a small change in the code because NBExternalAdress >>>> does >>>> >>> >> not >>>> >>> >> inherit from NBExternalStructure anymore. It is safe?. I mean so >>>> far >>>> >>> >> no >>>> >>> >> problems but my understanding is limited so I haven't make any >>>> commit. >>>> >>> >> >>>> >>> >> getGlobalSymbolPointer: symbolName >>>> >>> >> | bytes addr | >>>> >>> >> bytes := ByteArray new: 8. >>>> >>> >> self bootstrapGetGlobalSymbolPointer: symbolName into: bytes. >>>> >>> >> addr := bytes unsignedLongAt: 1 bigEndian: false. >>>> >>> >> addr = 0 >>>> >>> >> ifTrue: [self error: 'failed to get a symbol address: ' , >>>> symbolName]. >>>> >>> >> +^ NBExternalAddress ulongAt: addr >>>> >>> >> -^ NBExternalAddress value: addr >>>> >>> >> >>>> >>> >> Cheers >>>> >>> > >>>> >>> > >>>> >>> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Best regards, >>>> >>> Igor Stasenko. >>>> >>> >>>> >> >>>> > >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>> >> >

Jan. 12, 2013

Re: [Pharo-users] Change in NativeLinux32>>getGlobalSymbolPointer

by Jesus NuÃ±ez

Hi Igor, Promise the last question today. What can be causing that issuing: > "NativeBoost forCurrentPlatform callbackCounterAddress. " returns "nil" ?. In the trunk 1.8 is OK and it returns "@16r282000" in my case. Thanks in advance, Jesus 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> > Sorry what operation should I do over the new versions in Montincello to > load them safely?? > > > 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> > >> Yes Ok, I got it. The question is that the #value: selector is still >> there, with the old code. Sorry, I should have check the new code directly >> in the repository and compare it. >> >> Thank you. >> >> >> 2013/1/12 Igor Stasenko <siguctua(a)gmail.com> >> >>> On 12 January 2013 19:00, Jesus NuÃ±ez <poissonbreaker(a)gmail.com> wrote: >>> > BTW I also tried returning with ";yourself" but no luck in the test I >>> made. >>> > >>> > >>> i dont know what you trying to change there. this code works fine, >>> because >>> if it would not, then nothing else would work at all. >>> >>> >>> > 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> >>> >> >>> >> Ok, but happens that #value: uses #fieldAt: was inherited from >>> >> NBExternalStructure, which is no longer in the hierarchy. But I >>> understand >>> >> that it will no longer work with the change I made, any idea? >>> >> >>> >> >>> >> Best Regards, >>> >> >>> >> Jesus >>> >> >>> >> >>> >> 2013/1/12 Igor Stasenko <siguctua(a)gmail.com> >>> >>> >>> >>> No, it should be >>> >>> NBExternalAddress value: addr >>> >>> because method should answer an instance of NBExternalAddress >>> >>> not integer. >>> >>> >>> >>> On 12 January 2013 15:25, Jesus NuÃ±ez <poissonbreaker(a)gmail.com> >>> wrote: >>> >>> > Sorry. NBExternalAddress new ulongAt: adress >>> >>> > >>> >>> > >>> >>> > 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> >>> >>> >> >>> >>> >> I have made a small change in the code because NBExternalAdress >>> does >>> >>> >> not >>> >>> >> inherit from NBExternalStructure anymore. It is safe?. I mean so >>> far >>> >>> >> no >>> >>> >> problems but my understanding is limited so I haven't make any >>> commit. >>> >>> >> >>> >>> >> getGlobalSymbolPointer: symbolName >>> >>> >> | bytes addr | >>> >>> >> bytes := ByteArray new: 8. >>> >>> >> self bootstrapGetGlobalSymbolPointer: symbolName into: bytes. >>> >>> >> addr := bytes unsignedLongAt: 1 bigEndian: false. >>> >>> >> addr = 0 >>> >>> >> ifTrue: [self error: 'failed to get a symbol address: ' , >>> symbolName]. >>> >>> >> +^ NBExternalAddress ulongAt: addr >>> >>> >> -^ NBExternalAddress value: addr >>> >>> >> >>> >>> >> Cheers >>> >>> > >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> >>> Igor Stasenko. >>> >>> >>> >> >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> >

Jan. 12, 2013

Re: [Pharo-users] Change in NativeLinux32>>getGlobalSymbolPointer

by Jesus NuÃ±ez

Sorry what operation should I do over the new versions in Montincello to load them safely?? 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> > Yes Ok, I got it. The question is that the #value: selector is still > there, with the old code. Sorry, I should have check the new code directly > in the repository and compare it. > > Thank you. > > > 2013/1/12 Igor Stasenko <siguctua(a)gmail.com> > >> On 12 January 2013 19:00, Jesus NuÃ±ez <poissonbreaker(a)gmail.com> wrote: >> > BTW I also tried returning with ";yourself" but no luck in the test I >> made. >> > >> > >> i dont know what you trying to change there. this code works fine, because >> if it would not, then nothing else would work at all. >> >> >> > 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> >> >> >> >> Ok, but happens that #value: uses #fieldAt: was inherited from >> >> NBExternalStructure, which is no longer in the hierarchy. But I >> understand >> >> that it will no longer work with the change I made, any idea? >> >> >> >> >> >> Best Regards, >> >> >> >> Jesus >> >> >> >> >> >> 2013/1/12 Igor Stasenko <siguctua(a)gmail.com> >> >>> >> >>> No, it should be >> >>> NBExternalAddress value: addr >> >>> because method should answer an instance of NBExternalAddress >> >>> not integer. >> >>> >> >>> On 12 January 2013 15:25, Jesus NuÃ±ez <poissonbreaker(a)gmail.com> >> wrote: >> >>> > Sorry. NBExternalAddress new ulongAt: adress >> >>> > >> >>> > >> >>> > 2013/1/12 Jesus NuÃ±ez <poissonbreaker(a)gmail.com> >> >>> >> >> >>> >> I have made a small change in the code because NBExternalAdress >> does >> >>> >> not >> >>> >> inherit from NBExternalStructure anymore. It is safe?. I mean so >> far >> >>> >> no >> >>> >> problems but my understanding is limited so I haven't make any >> commit. >> >>> >> >> >>> >> getGlobalSymbolPointer: symbolName >> >>> >> | bytes addr | >> >>> >> bytes := ByteArray new: 8. >> >>> >> self bootstrapGetGlobalSymbolPointer: symbolName into: bytes. >> >>> >> addr := bytes unsignedLongAt: 1 bigEndian: false. >> >>> >> addr = 0 >> >>> >> ifTrue: [self error: 'failed to get a symbol address: ' , >> symbolName]. >> >>> >> +^ NBExternalAddress ulongAt: addr >> >>> >> -^ NBExternalAddress value: addr >> >>> >> >> >>> >> Cheers >> >>> > >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> Best regards, >> >>> Igor Stasenko. >> >>> >> >> >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >

Jan. 12, 2013