- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ESUG gentle actions reminder

by Igor Stasenko

On 10 March 2010 09:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > who knows? > Some people with a small vision :) > > And may be some people may not have noticed that over the years some open source dialect got a lot out of ESUG > and they could insinuate that ESUG coudl be against it. > We did not put all the cost of the actions because we are not that picky > but a project is about 2500 Euros, and summertalk was 1500 Euros now 2500 Euros > and cleaning Squeak VM for example cost several project cost. > I think all of above is only a tiny glipse of ESUG good deeds towards supporting smalltalk. The main thing, i think, is hosting and organizing a conference, which is great world-wide event for all smalltalkers. > Probably because people do not study at school Â history and are bad in statistics nowadays but prefer marketing :). > > Stef > > > > On Mar 9, 2010, at 10:57 PM, Igor Stasenko wrote: > >> On 9 March 2010 23:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Dear Smalltalkers of all dialects! >>> >>> In a time where Â Â Â Â we are bombarded with information and may be misinformed :), >>> some of you may not notice that ESUG is doing a great job pushing Smalltalk, we thought that it is good >>> Â to get a gentle reminder on the main actions ESUG performed in the past. http://www.esug.org >>> Yes we have been busy promoting the language we all love. :) >>> >>> The board. >>> >> >> I hardly believe that there is anyone who thinks that ESUG is evil :) >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > 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.

March 10, 2010

Re: [Pharo-project] VM crash on Windows

by Schwab,Wilhelm K

Andreas, I will give that a try. I think it should be active by default, but it won't matter too much once I modify the shortcuts on a few boxes. Other wish list items would be to have a similar option on Linux and to ensure that the contents of the log are concatenated vs. replaced with each crash. Thanks!! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Andreas Raab Sent: Wednesday, March 10, 2010 12:32 AM To: Pharo Development Subject: Re: [Pharo-project] VM crash on Windows Hi Bill - If you have problems like these consider cross-posting to squeak-dev or vm-dev. I only check Pharo in irregular intervals. On 3/8/2010 4:27 PM, Schwab,Wilhelm K wrote: > I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. The issue you're seeing is caused by a recursive MessageNotUnderstood error. You can easily recreate this by doing the following: ((ProtoObject subclass: #Bummerator instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Objects') superclass: nil; new) bummer. The reason why that doesn't result in a regular crash.dmp is that the support code (which catches the crashes and writes the dump) isn't involved at all. The interpreter just quits. Contrast this with, say the result of an FFI crash: (ExternalLibraryFunction name:'' module: '' callType: 0 returnType: ExternalType void argumentTypes: #()) setHandle: ((ExternalAddress new) at: 1 put: 1; yourself); invoke This does generate a crash.dmp since the support code can catch the problem. However, to catch the former issue you can run the vm with -log: <logfile> which will contain the resulting output. > The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. They do if you tell 'em to. Cheers, - Andreas _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 10, 2010

Re: [Pharo-project] Collection >> collectDistinct: ??

by Mariano Martinez Peck

hahhha thanks Nicolas..I was sure somewhere it should be...I was blind...weird I check there!!! thanks a lot. mariano On Wed, Mar 10, 2010 at 2:07 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > self collect: aBlock as: Set > > 2010/3/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi. I was needing something like the SQL select distinct, that doesn't > take > > into account repeated objects. I didn't found anything useful in > Collection, > > and thus, I have implemented this: > > > > Collection >> collectDistinct: aBlock > > > > > > collectDistinct: aBlock > > "Evaluate aBlock with each of the receiver's elements as the > argument. > > Collect the resulting values into a Set, thus repeated objects will > not > > be present. > > Answer the new collection." > > > > | newSet | > > newSet := self species new asSet. > > self do: [:each | newSet add: (aBlock value: each)]. > > ^ newSet > > > > > > Is there a better way ? Do you think it make sense to put this in Pharo > ? > > > > Cheers > > > > Mariano > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 10, 2010

Re: [Pharo-project] Collection >> collectDistinct: ??

by Nicolas Cellier

self collect: aBlock as: Set 2010/3/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi. I was needing something like the SQL select distinct, that doesn't take > into account repeated objects. I didn't found anything useful in Collection, > and thus, I have implemented this: > > Collection >> collectDistinct: aBlock > > > collectDistinct: aBlock > Â Â Â "Evaluate aBlock with each of the receiver's elements as the argument. > Â Â Â Collect the resulting values into a Set, thus repeated objects will not > be present. > Â Â Â Answer the new collection." > > Â Â Â | newSet | > Â Â Â newSet := self species new asSet. > Â Â Â self do: [:each | newSet add: (aBlock value: each)]. > Â Â Â ^ newSet > > > Is there a better way ?Â Â Do you think it make sense to put this in Pharo ? > > Cheers > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 10, 2010

[Pharo-project] Collection >> collectDistinct: ??

by Mariano Martinez Peck

Hi. I was needing something like the SQL select distinct, that doesn't take into account repeated objects. I didn't found anything useful in Collection, and thus, I have implemented this: Collection >> collectDistinct: aBlock collectDistinct: aBlock "Evaluate aBlock with each of the receiver's elements as the argument. Collect the resulting values into a Set, thus repeated objects will not be present. Answer the new collection." | newSet | newSet := self species new asSet. self do: [:each | newSet add: (aBlock value: each)]. ^ newSet Is there a better way ? Do you think it make sense to put this in Pharo ? Cheers Mariano

March 10, 2010

Re: [Pharo-project] Full time engineer position for Pharo looking for cool engineer :)

by StÃ©phane Ducasse

cooooooooooool do you have a link for the web page of success stories :) Stef On Mar 10, 2010, at 12:06 PM, Hernan Wilkinson wrote: > BTW, at the University of Buenos Aires we are going to use Pharo this year (and the next ones). Four years ago we were using Squeak, then we went to VisualWorks but now Pharo is mature enough to use it as development environment so, we are going back to an open source implementation. > > Hernan. > > On Wed, Mar 10, 2010 at 4:47 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Something really important that I forgot to say. > Thanks to all of you that are making Pharo cool. > The key point is that of course we wrote a request document (10 pages), went to meetings to understand what they wanted, rewrote the document, > motivated it,... > But at the end the fact that INRIA supports pharo is not because of us but because of you and the impact they see. > So all the submissions, users, mailing-list traffic... counts. > So just replying to emails mentioning that you use pharo to > do research > teach > develop applications > was already a good action :) > > Thanks since I forget to mention it. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 10, 2010

Re: [Pharo-project] Full time engineer position for Pharo looking for cool engineer :)

by Hernan Wilkinson

BTW, at the University of Buenos Aires we are going to use Pharo this year (and the next ones). Four years ago we were using Squeak, then we went to VisualWorks but now Pharo is mature enough to use it as development environment so, we are going back to an open source implementation. Hernan. On Wed, Mar 10, 2010 at 4:47 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Something really important that I forgot to say. > Thanks to all of you that are making Pharo cool. > The key point is that of course we wrote a request document (10 pages), > went to meetings to understand what they wanted, rewrote the document, > motivated it,... > But at the end the fact that INRIA supports pharo is not because of us but > because of you and the impact they see. > So all the submissions, users, mailing-list traffic... counts. > So just replying to emails mentioning that you use pharo to > do research > teach > develop applications > was already a good action :) > > Thanks since I forget to mention it. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 10, 2010

Re: [Pharo-project] Full time engineer position for Pharo looking for cool engineer :)

by Hernan Wilkinson

Hey, this is great! congratulations to all the people at Inria that are pushing this! Hernan. On Mon, Mar 8, 2010 at 5:36 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi guys > > Some good news :) > INRIA-lille nord Europe ranked Pharo among the top 3 projects that will > receive support for a full time confirmed engineer. > We will know if the national level or the lab will carry the cost by mid > april, but for now the position is allocated to Pharo. > > This is not the official job announce but just to give some hints and that > you can prepare yourself to > - move to France (one hour from paris, 1h30 from London, 35 min from > Brussels) > - try a lot of good beers (belgium :) > - eat french food > - have fun with us - yes we are even fun - ok with geeky humor :) > - code all the day in Smalltalk and a bit of C > > Apparently from what the DHR services told me, the salary will depend on > years of expertise and diplomas but > we can think that 2700 Euros (before final taxes) should be a good working > number -- In France the employer pays already taxes so the salary is not > brutto but already includes deduction. The social insurance is included and > you may want to pay an extra like me (100 Euros) to have a better health > insurance. Lille is an active city but not expensive. To give an idea Marcus > got a nice sunny close to everything flat with wooden floor for 650 Euros. > > The job will to continue making Pharo (core) better > - better tools > - better network support > - helping with the new compiler > - helping with alien and others > - cleaning/shrinking > > Duration: 30 months > Starting date: October 2010 > Location: Lille (no remote job possible) > > Do not hesitate to contact us. > > Stef/Marcus > > > > > ------------------------ > Dr. StÃ©phane Ducasse -- Directeur de Recherche (Senior Researcher) > INRIA - USTL - CNRS UMR 8022 > stephane.ducasse(a)inria.fr > http://stephane.ducasse.free.fr > http://rmod.lille.inria.fr/ > **NEW ***Tel 00 33 (0)3 20 43 42 56 - Fax 33 3 59 57 78 50 > > 40, avenue Halley, Parc Scientifique de la Haute Borne, > BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France. > > "if you knew today was your last day on earth, what would you > do different? ... especially if, by doing something different, > today might not be your last day on earth" Calvin&Hobbes > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 10, 2010

Re: [Pharo-project] Something I don't understand with ImageSegments

by Mariano Martinez Peck

On Fri, Feb 19, 2010 at 12:35 AM, Sheridan Mahoney < sheridan(a)sheridan-mahoney.com> wrote: > > Hi all, > > I've been catching up on ImageSegment news, and came across this old post > from January, > and got interested in discovering the mindset behind the outPointers array. > I re-ran > Mariano's original test code, with a small change: turned 'Object new' > into > TestOutPointers, a new > subclass of Object, with 2 inst vars and one method. I'd be interested in > getting feedback on > whether my guesses (in quotes below) are in the ball park. The results > seem > to explain why > Association is not in outPointers - what is captured there in the case of > adding a class > is a lot like what you would need for filling in a class template. If you > add an instance of a class, > you just need the name of the class. > > Some comments I have gleaned from the ImageSegment class on outPointers : > This array contains: > - OOPs of all objects outside the segment that are pointed to from > inside segment. > - outPointers that are necessary to turn the bits in the file into > objects. > > Here's the code: > > | segment external internal root | > > external := TestOutpointers. > internal := true -> external. > root := false -> internal. > internal := nil. > > segment := ImageSegment new > copyFromRoots: (Array with: root with: external) > sizeHint: 5000 > areUnique: true. > ok > ^ (segment outPointers ) -> (segment arrayOfRoots ) > I don't understand what is this return and why the association. > > ====== result ================= > { false. "object outside the segment that is > pointed to from inside segment." > Object. "superclass of TestOutpointers" > a MethodDictionary(#tryList->a CompiledMethod(1725: > TestOutpointers>>tryList) ) "MethodDictionary" > #('iv1' 'iv2') "inst var names" > ('testing' tryList) "method category" > nil. "object outside the segment that is > pointed to from inside segment." > #TestOutpointers. "symbol representing name of new class" > Smalltalk. "environment that TestOutpointers is > assigned to" > #'IST-outPointers'. "category name for TestOutpointers" > true. "object outside the segment that is > pointed to from inside segment." > Metaclass. "for initializing class variables and > instance creation messages particular to a class." > Object class. "class of TestOutpointers superclass" > ClassOrganizer. "need this in order to determine whether > TestOutpointers has been changed in the local env" > #'as yet unclassified'. "??" > } > For me this is ok. #'as yet unclassified'. "??" in my case shows: ('as yet unclassified' xxxMethod) where xxxMethod is the method I defined in TestOutPointers and 'as yet unclassified' is because you didn't define any category to that method. If you inspect ('as yet unclassified' xxxMethod) you will see it is a ClassOrganizer I also attach a pdf I wrote about ImageSegment (is much more updated than the one I sent you months before). Cheers Mariano > -> > {false->true->TestOutpointers. TestOutpointers} > > > > Any feedback would be very welcome... > > Cheers, > Sheri > > -- > View this message in context: > http://n4.nabble.com/Something-I-don-t-understand-with-ImageSegments-tp1296… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 10, 2010

Re: [Pharo-project] [update 1.1] #11255

by Mariano Martinez Peck

On Wed, Mar 10, 2010 at 8:51 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> It seems there is a problem as cleanUp or cleanUp: are implemented in > > SmalltalkImage but not in SystemDictionary...so evaluating > > > > Smalltalk cleanUp. > > Smalltalk cleanUp: true. > > > > gives a DNU. > > > > Another question....wouldn't be a good idea to add at least a "Smalltalk > > cleanUp. " in ScriptLoader >> cleanUpForRelease ??? or similar.... > > Yes. And when we adopt the cleanUp protocol, the stuff in cleanUpForRelease > should be moved into the appropriate classes. > http://code.google.com/p/pharo/issues/detail?id=2130 > > Cheers, > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 10, 2010