Re: [Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file

Thanks! and welcome back. Stef On Oct 11, 2010, at 7:16 AM, Sheridan Mahoney wrote: > I've just re-entered the Pharo world after a long(ish) absence, and wanted to > report a > new bug submission; here's the breakdown: > > Pharo image: dev > Pharo core version: Pharo-1.1.1-- Latest update:

Re: [Pharo-project] Getting my head around low space

"There is not enough memory to give squeak the amount specified by the 'memory EMBED tag.". Additionally there's a "Premature end of file" error on the image and then the VM crashes (OS X crash dialog). Issuing the same commands with 1 GB memory works fine (no problems with the image). Interest

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. ISSUE 2653. http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty I did a test, maybe a good start would be to see if its failing now. F

Re: [Pharo-project] Xtreams port to Squeak - second wave

Hi Nicolas, You have been working quite quickly, great! I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report. I have been trying some of the exa

Re: [Pharo-project] another little OB "bug"

I investigated PluggableListMorph and ListMorph, the problem you describe is there (likely this should be fixed in Pharo). In Name: OB-Morphic-lr.149 Author: lr Time: 11 October 2010, 10:17:53 am UUID: 285339d9-f9da-4c6d-98b9-e09ea154c91e Ancestors: OB-Morphic-lr.148 - more efficient

Re: [Pharo-project] 12186 image quit problem

Ok, I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3091 The patch works for me, Thank you Igor. Cheers, -- Pavel On Sun, Oct 10, 2010 at 6:46 PM, Igor Stasenko wrote: > On 10 October 2010 17:40, Schwab,Wilhelm K wrote:

Re: [Pharo-project] another little OB "bug"

On Mon, Oct 11, 2010 at 10:18 AM, Lukas Renggli wrote: > I investigated PluggableListMorph and ListMorph, the problem you > describe is there (likely this should be fixed in Pharo). In > > Name: OB-Morphic-lr.149 > Author: lr > Time: 11 October 2010, 10:17:53 am > UUID: 285339d9-f9da-4c6d-98b

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

> > > ? > In any way, passing anything else than block literal as argument should work. You mean in the implementation or in the semantics? Read my mail. This is a question of semantics. The argument of iftrue:ifFalse: are thunk (piece of code with frozen execution). > This is smalltalk, not C

[Pharo-project] [update 1.2] #12188

12188 - - Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. - Issue 2875: PharoKernel Part 11. Thanks Pavel Krivanek and Nicolas Paes Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.in

Re: [Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file

For convenience, this is the link to the issue: http://code.google.com/p/pharo/issues/detail?id=3090 I suspect that this bug is related to the new block closures. Adrian On Oct 11, 2010, at 07:15 , Sheridan Mahoney wrote: > I've just re-entered the Pharo world after a long(ish) absence, and wa

Re: [Pharo-project] 12186 image quit problem

I integrate Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. http://code.google.com/p/pharo/issues/detail?id=3086 Igor can you have a look and let me know: 1- if we should rollback Issue 3086:MCMethodDefinition>>shutdown hack to avoid lo

Re: [Pharo-project] [Moose-dev] pharo sprint / moose dojo - october 23-24, bern

Hi, Some guys from North of France cannot come to Bern. So we propose to make a shared session with you, but localized at LIFL, Villeneuve d'Ascq. We can do it during the two days. http://code.google.com/p/pharo/wiki/PharoSprints Cheers, Jannik On Sep 27, 2010, at 22:36 , Tudor Girba wrote

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

On Oct 10, 2010, at 3:13 08PM, Stéphane Ducasse wrote: > personnally I do not like this form > What does it do? > >> process ifNotNil: #terminate. > > > for me it means passes the symbol #terminate as argument to the method > ifNotNil: > If it has a more magical behavior then I do not know

Re: [Pharo-project] [Moose-dev] pharo sprint / moose dojo - october 23-24, bern

Sounds good. We just have to see about the technical details. Cheers, Doru On 11 Oct 2010, at 11:17, Laval Jannik wrote: > Hi, > > Some guys from North of France cannot come to Bern. > So we propose to make a shared session with you, but localized at LIFL, > Villeneuve d'Ascq. > > We can do

[Pharo-project] Pharo by Example has moved to github

See: http://github.com/SquareBracketAssociates/ Cheers, - on ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] 12186 image quit problem

On 11 October 2010 12:10, Stéphane Ducasse wrote: > I integrate >        Issue 3086:     MCMethodDefinition>>shutdown hack to avoid lock down. >        http://code.google.com/p/pharo/issues/detail?id=3086 > > > > Igor can you have a look and let me know: >        1- if we should rollback Issue 308

[Pharo-project] Fwd: [Moose-dev] Re: pharo sprint / moose dojo - october 23-24, bern

Begin forwarded message: > From: Tudor Girba > Date: October 11, 2010 11:38:54 GMT+02:00 > To: Pharo-project@lists.gforge.inria.fr > Cc: Moose-related development , notre liste > > Subject: [Moose-dev] Re: [Pharo-project] pharo sprint / moose dojo - october > 23-24, bern > Reply-To: Moose-re

[Pharo-project] Hallo Pharoers.. namespaces in the system level ?

*Hallo to all, * I am starting my Ph.D on 'languages and environments for autonomous robotics' -- and pharo will be a huge part of it. I am currently playing around with the system (to get the feel of it..) and testing it's programming tools in the context of different namespaces / environments.

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

> personnally I do not like this form >> What does it do? >> >>> process ifNotNil: #terminate. >> >> >> for me it means passes the symbol #terminate as argument to the method >> ifNotNil: >> If it has a more magical behavior then I do not know it. >> >> Stef > > It's exactly the same as usin

Re: [Pharo-project] 12186 image quit problem

Thanks. So let's see what is the best choice and tell us. On Oct 11, 2010, at 11:47 AM, Igor Stasenko wrote: > On 11 October 2010 12:10, Stéphane Ducasse wrote: >> I integrate >>Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. >>http://code.google.com/p/phar

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

On 11 October 2010 13:53, Stéphane Ducasse wrote: >> personnally I do not like this form >>> What does it do? >>>  process ifNotNil: #terminate. >>> >>> >>> for me it means passes the symbol #terminate as argument to the method >>> ifNotNil: >>> If it has a more magical behavior then I do no

Re: [Pharo-project] [squeak-dev] Re: 12186 image quit problem

- i added a test to cover this issue http://code.google.com/p/pharo/issues/detail?id=3092 On 11 October 2010 14:01, Stéphane Ducasse wrote: > Thanks. > So let's see what is the best choice and tell us. > > > On Oct 11, 2010, at 11:47 AM, Igor Stasenko wrote: > >> On 11 October 2010 12:10, Stéphan

Re: [Pharo-project] Adding a new font in System like DejaVu fonts

On Oct 10, 2010, at 12:49 40PM, nullPointer wrote: > > Now I know is possible add a new font, for use cross platform like DejaVu. I > know Juan Vuletich did that but I don´t know found the place of that is > explained. Is heard do that? Whuups, might've sent you in a wild goose chase, sorry :/

Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak

This still seems confusing. Could we just have a new SqueakSource project called "Xtreams" (small T + an S)? It's not like projects are expensive to create... Julian On Sat, Oct 9, 2010 at 11:33 PM, Nicolas Cellier wrote: > So, I started a quick port of VW Xtreams to Squeak this evening. > Only

[Pharo-project] Migration Manual for Pharo 1.1 ?

Hi Folks, I just wanted to install my work on version 1.1 and was surprised to discover changes which leave me alone to find out for myself how to change my code : WorldMenu (I wrote a subclass of PasteUpMorph) NaturalLanguageTranslator (what is the "gettext package" mentioned in the class co

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

> Object>>value >        ^self > > What actually shown here is a use of duck typing, because any object, > which implemets #value, could be safely passed > as argument to #ifTrue:ifFalse: message. > It is well consistent with language design. Magritte implemented Symbol>>#value: for a while before

Re: [Pharo-project] another little OB "bug"

>>  Name: OB-Morphic-lr.149 >>  Author: lr >>  Time: 11 October 2010, 10:17:53 am >>  UUID: 285339d9-f9da-4c6d-98b9-e09ea154c91e >>  Ancestors: OB-Morphic-lr.148 >> >>  - more efficient fix for list updating >> >> I try to remember the current scroll position before updating any OB >> list, so I gu

[Pharo-project] Another finalization concern: error handling

Hello, here a situation, with which we can deal in more safer manner: Suppose you have a weak registry, populated by different objects and their executors. Now, when some of them died, a weak registry performs finalization. The potential danger is , that if there's an error triggered by some ex

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

On 11 October 2010 14:28, Lukas Renggli wrote: >> Object>>value >>        ^self >> >> What actually shown here is a use of duck typing, because any object, >> which implemets #value, could be safely passed >> as argument to #ifTrue:ifFalse: message. >> It is well consistent with language design. >

Re: [Pharo-project] Another finalization concern: error handling

On 11 October 2010 14:40, Igor Stasenko wrote: > Hello, > > here a situation, with which we can deal in more safer manner: > > Suppose you have a weak registry, populated by different objects and > their executors. > > Now, when some of them died, a weak registry performs finalization. > > The pot

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?

Le 11/10/2010 13:27, Johannes Rasche a écrit : Hi Folks, I just wanted to install my work on version 1.1 and was surprised to discover changes which leave me alone to find out for myself how to change my code : WorldMenu (I wrote a subclass of PasteUpMorph) NaturalLanguageTranslator (what

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?

Hi we should improve from that side, but unfortunately we do not have enough man power to build tool that could support it. Stef On Oct 11, 2010, at 1:28 PM, Johannes Rasche wrote: > Hi Folks, > > I just wanted to install my work on version 1.1 and was surprised > to discover changes which l

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

>> >> >> Now to me this looks like a hack and again it works because now Symbol are >> valuable objects. >> Too many hacks will only make the system more hackish. >> And especially the >>iftrue: 'foo' ifFalse: 'zork' >> > > This is not a hack, because if you refer to implementation: >

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

On Oct 11, 2010, at 1:28 PM, Lukas Renggli wrote: >> Object>>value >>^self >> >> What actually shown here is a use of duck typing, because any object, >> which implemets #value, could be safely passed >> as argument to #ifTrue:ifFalse: message. >> It is well consistent with language desi

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

On 11 October 2010 15:18, Stéphane Ducasse wrote: >>> >>> >>> Now to me this looks like a hack and again it works because now Symbol are >>> valuable objects. >>> Too many hacks will only make the system more hackish. >>> And especially the >>>        iftrue: 'foo' ifFalse: 'zork' >>> >> >> This

Re: [Pharo-project] [squeak-dev] Re: WeakRegistry>>remove: - when you'll be in trouble

Dave, Since when? Even if operating systems started universally covering for such mistakes, I still would not recommend testing them on it. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?

2010/10/11 Johannes Rasche > Hi Folks, > > I just wanted to install my work on version 1.1 and was surprised > to discover changes which leave me alone to find out for myself how to > change my code : > > WorldMenu (I wrote a subclass of PasteUpMorph) > NaturalLanguageTranslator (what is the "g

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

On Mon, 11 Oct 2010, Lukas Renggli wrote: Object>>value        ^self What actually shown here is a use of duck typing, because any object, which implemets #value, could be safely passed as argument to #ifTrue:ifFalse: message. It is well consistent with language design. Magritte implemented S

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

>> I eventually removed Symbol>>#value: for good. Re-occuring questions >> in the mailing list disappeared. > > That's strange, because Symbol >> #value: was added to Squeak in 2006 during > the developement of 3.9. Why? Filename: Magritte-All-lr.185.mcz Author: Lukas Renggl

Re: [Pharo-project] MicroSqueak [was System Tracer]

Thanks indeed to John and to you Eliot. Noury On 9 oct. 2010, at 03:48, Eliot Miranda wrote: > Hi All, > > I'm please to let you know that John Maloney has published his > MicroSqueak code on his website under the MIT license. > http://web.media.mit.edu/~jmaloney/microsqueak/ > Apologies

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

Hi Nick, Stef and I worked on an implementation a few years ago. http://www.squeaksource.com/Namespace.html Cheers, Alexandre On 11 Oct 2010, at 07:53, Nick Papoylias wrote: > Hallo to all, > > I am starting my Ph.D on 'languages and environments for autonomous robotics' > -- and pharo will

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

On Mon, 11 Oct 2010, Lukas Renggli wrote: I eventually removed Symbol>>#value: for good. Re-occuring questions in the mailing list disappeared. That's strange, because Symbol >> #value: was added to Squeak in 2006 during the developement of 3.9. Why? Filename: Magritte-All-lr.185.mcz

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

Also, i remember someone presented the namespaces implementation during last ESUG conference. Its fresh, and probably will run on pharo. But i don't remember who did this. On 11 October 2010 16:10, Alexandre Bergel wrote: > Hi Nick, > > Stef and I worked on an implementation a few years ago. > ht

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

On 11 oct. 2010, at 15:17, Igor Stasenko wrote: > Also, i remember someone presented the namespaces implementation > during last ESUG conference. Its fresh, and probably will run on pharo. > But i don't remember who did this. Here you go, it's a GSOC project, video included: Begin forwarded m

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

>>  Filename:      Magritte-All-lr.185.mcz >>  Author:                Lukas Renggli >>  Timestamp:     19 January 2007 2:25:14 pm >>  UUID:          e26ba5b5-15b0-4128-9839-1536359b89f0 >>  Ancestors:     Magritte-All-lr.184.mcz >> >>  - removed #value: and #value:value: from Symbol (this is now in

[Pharo-project] [update 1.2] #12189

12189 - - Issue 2883: Anymorphic Style. Thanks Anymorphic and Nicolas Paez. - Issue 2979: Controlling UI feedback. BlockClosure>>silentlyValue ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-b

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

> > > Stef and I worked on an implementation a few years ago. > http://www.squeaksource.com/Namespace.html And it is a bad one :) Now we are working on making the system environment-aware so that we can browse part of the system, (remotely too with you). Stef > > Cheers, > Alexandre > > > O

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

We already integrated the fixes for the systemOrganization he did. More is needed. Stef On Oct 11, 2010, at 3:23 PM, Simon Denier wrote: > > On 11 oct. 2010, at 15:17, Igor Stasenko wrote: > >> Also, i remember someone presented the namespaces implementation >> during last ESUG conference. Its

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

>> That "hack" is really cool IMO. The code is easily understood by anyone: > > #(4 1 3 5 2) sort: #<=. yes in Moose people are using that a lot for scripting. Now the problem is that as soon as you need more you have to get a block. Stef ___ Pharo-pr

Re: [Pharo-project] Another finalization concern: error handling

On Mon, 11 Oct 2010, Igor Stasenko wrote: Hello, here a situation, with which we can deal in more safer manner: Suppose you have a weak registry, populated by different objects and their executors. Now, when some of them died, a weak registry performs finalization. The potential danger is ,

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

On Mon, 11 Oct 2010, Stéphane Ducasse wrote: That "hack" is really cool IMO. The code is easily understood by anyone: #(4 1 3 5 2) sort: #<=. yes in Moose people are using that a lot for scripting. Now the problem is that as soon as you need more you have to get a block. Why is that a pro

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

I'm glad to see that it works like class names (at least effectively) as messages to environments than a clone of Java syntax that I saw elsewhere. On the completely pragmatic level, it will make more obvious the fact that our browser selection panes are not individually sizable. I find them

Re: [Pharo-project] Another finalization concern: error handling

Levente, A similar discussion arose around Dolphin's event (#trigger*) mechanism. My recollection is that it was not fully addressed due to performance concerns. Forking and error handlers both have their costs. I'm not saying we should necessarily follow (we probably should not), though wit

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

On 11 October 2010 16:59, Schwab,Wilhelm K wrote: > I'm glad to see that it works like class names (at least effectively) as > messages to environments than a clone of Java syntax that I saw elsewhere.   > On the completely pragmatic level, it will make more obvious the fact that > our browser s

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?

Thanks Alain, Stef and Mariano for fast answer. I assume that will help. Possibly I can contribute to improve documentation by carefull reading, trying and so on Johannes Am 11.10.2010 um 14:51 schrieb Mariano Martinez Peck: > > > 2010/10/11 Johannes Rasche > Hi Folks, > > I just wanted t

Re: [Pharo-project] Another finalization concern: error handling

On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: Levente, A similar discussion arose around Dolphin's event (#trigger*) mechanism. My recollection is that it was not fully addressed due to performance concerns. Forking and error handlers both have their costs. I'm not saying we should necessa

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

The UI changes are indeed a separate problem; if anything, this will make them more likely to happen as more people will run into the need for more space in the class and method columns at the expense of the others. Agreed that it looks like a smooth way to add the functionality. _

Re: [Pharo-project] [squeak-dev] Re: Another finalization concern: error handling

On 11 October 2010 16:51, Levente Uzonyi wrote: > On Mon, 11 Oct 2010, Igor Stasenko wrote: > >> Hello, >> >> here a situation, with which we can deal in more safer manner: >> >> Suppose you have a weak registry, populated by different objects and >> their executors. >> >> Now, when some of them d

Re: [Pharo-project] Another finalization concern: error handling

Levente, Ok, but just because the system saves us at the last instant does not mean that we should be going out of our way to multiply free external resources. Files are well known to the vm; other things (GSL vectors/matrices comes to mind) will not enjoy such protections. This strikes me as

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

On Oct 11, 2010, at 3:55 PM, Levente Uzonyi wrote: > On Mon, 11 Oct 2010, Stéphane Ducasse wrote: > That "hack" is really cool IMO. The code is easily understood by anyone: >>> >>> #(4 1 3 5 2) sort: #<=. >> >> yes in Moose people are using that a lot for scripting. Now the problem is >>

[Pharo-project] [update 1.2] #12190

12190 - - Issue 3065: HardCoded SystemOrganization references. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

Ok, first of all thank you all ! It' s definetely a nice welcome for me, from the list. Let me point out one things or two though: It whould be nice to have PEPs (Pharo Enhancement Proposals), for these major issues. See PEP for Python: http://www.python.org/dev/peps/ . Smalltalk is so powerfull

Re: [Pharo-project] [squeak-dev] Re: Another finalization concern: error handling

On Mon, 11 Oct 2010, Igor Stasenko wrote: On 11 October 2010 16:51, Levente Uzonyi wrote: On Mon, 11 Oct 2010, Igor Stasenko wrote: Hello, here a situation, with which we can deal in more safer manner: Suppose you have a weak registry, populated by different objects and their executors. No

Re: [Pharo-project] [squeak-dev] Re: Another finalization concern: error handling

Dolphin has all of its required processes rigged to restart themselves if terminated; we must follow that lead. As far as getting error information from one thread to another, in one case I grab a callstack (just the This>>that, That>>this text with line feeds) and capture it to be included as

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

On Mon, 11 Oct 2010, Stéphane Ducasse wrote: On Oct 11, 2010, at 3:55 PM, Levente Uzonyi wrote: On Mon, 11 Oct 2010, Stéphane Ducasse wrote: That "hack" is really cool IMO. The code is easily understood by anyone: #(4 1 3 5 2) sort: #<=. yes in Moose people are using that a lot for scri

Re: [Pharo-project] Another finalization concern: error handling

On 11 October 2010 17:24, Levente Uzonyi wrote: > On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: > >> Levente, >> >> A similar discussion arose around Dolphin's event (#trigger*) mechanism. >>  My recollection is that it was not fully addressed due to performance >> concerns.  Forking and error hand

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

Nick, Just first reactions, but: (1) questions about integration with the browsers go to Lukas and others who are doing that work; (2) keep the design simple and consistent with "everything is an object, all computation happens by sending messages to objects" (3) use (2) vs. creating new syntax

Re: [Pharo-project] Another finalization concern: error handling

On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: Levente, Ok, but just because the system saves us at the last instant does not mean that we should be going out of our way to multiply free external resources. Files are well known to the vm; other things (GSL vectors/matrices comes to mind) will

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

I think that for typing in a transcript experessions when you want to experiment with something selectors are fun but not in method body. But I know that this is not a really good argument. Just feeling. May be we get trapped in our way of thinking. >> > I personally don't like the ifTrue

Re: [Pharo-project] Another finalization concern: error handling

On Mon, 11 Oct 2010, Igor Stasenko wrote: On 11 October 2010 17:24, Levente Uzonyi wrote: On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: Levente, A similar discussion arose around Dolphin's event (#trigger*) mechanism.  My recollection is that it was not fully addressed due to performance conc

Re: [Pharo-project] Pharo by Example has moved to github

Great Oscar ! How to join the SquareBracketAssociates ? On Mon, Oct 11, 2010 at 4:39 PM, Oscar Nierstrasz wrote: > > See: http://github.com/SquareBracketAssociates/ > > Cheers, > - on > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

Hi guys there is a HUGE HUGE HUGE difference between (1) namespace at the language level and we do not want that the way german did it. Give us some times and we will try different solutions and see what come out (2) systemDictionary at the infrastructure level. We are

Re: [Pharo-project] Another finalization concern: error handling

Sig, I'm not saying to leave the finalizer wide open to the wrath of errors from poorly coded objects. I am saying that we should strive for one finalizer per object (preferably the object itself) and that to get there, we need to make the registry thread safe and have some vm support. Failin

Re: [Pharo-project] Another finalization concern: error handling

On 11 October 2010 17:34, Schwab,Wilhelm K wrote: > Levente, > > Ok, but just because the system saves us at the last instant does not mean > that we should be going out of our way to multiply free external resources.   > Files are well known to the vm; other things (GSL vectors/matrices comes to

Re: [Pharo-project] Another finalization concern: error handling

GPL is a problem. It means that nothing I write on top of GSL gets out the door. However, I see no reason not to give others the same mix of capability and concern in the form of an interface to it. From: pharo-project-boun...@lists.gforge.inria.fr [

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

> > For example there currently exist a setter in the class side for 'migratting' > in a new environment, that just alters the class knowledge about the new > namespace and does not erase it's record from the old namespace. where? > Is this intented ? What is the underlying design ? Should we

Re: [Pharo-project] Pharo by Example has moved to github

Excellent, can I also push the Seaside Book there? The main data store remains Pier of course, but we already today keep the backups and other resources in the SCG SVN. Lukas On 11 October 2010 17:06, Serge Stinckwich wrote: > Great Oscar ! How to join the SquareBracketAssociates ? > > > On M

[Pharo-project] [update 1.2] #12191

12191 - - Issue 3092: Additional test for weak registry to check for deadlocks. Thanks Igor Stasenko. Issue 3093: Weaklings cleanup & fixes. Thanks Igor Stasenko. Igor the testFinalizationOfMultipleResources breaks, can you have a look? Stef ___

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

2010/10/11 Nick Papoylias : > Hallo to all, > > I am starting my Ph.D on 'languages and environments for autonomous > robotics' -- and pharo will be a huge part of it. Hi Nick, Great to see that another guy will work in the domain of embedded systems&autonomous robots with Smalltalk ! I already

Re: [Pharo-project] Another finalization concern: error handling

Argh >>> > > ObjectFinalizer>>finalize > "Finalize the resource associated with the receiver. This message > should only be sent during the finalization process. There is NO > garantuee that the resource associated with the receiver hasn't been > free'd before so take care that you don

Re: [Pharo-project] Another finalization concern: error handling

On Oct 11, 2010, at 4:10 13PM, Schwab,Wilhelm K wrote: > > I am far more worried about having multiple executors per object (when did > p=malloc();free(p);free(p);free(p) become good style?) than I am about > getting the finalizer process itself completely robust at this point. > > Bill I fa

Re: [Pharo-project] Pharo by Example has moved to github

> Excellent, can I also push the Seaside Book there? If you want. Now I do not see the interest of git when we use it as svn. And I would prefer to host the book on an inria server because I know that this is backup by someboyd else than me. and for a book I do not want to fork it (or people can

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

On Mon, Oct 11, 2010 at 5:11 PM, Stéphane Ducasse wrote: > > > > For example there currently exist a setter in the class side for > 'migratting' in a new environment, that just alters the class knowledge > about the new namespace and does not erase it's record from the old > namespace. > where? >

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?

Welcome and any help is welcome. On Oct 11, 2010, at 4:22 PM, Johannes Rasche wrote: > Thanks Alain, Stef and Mariano for fast answer. > > I assume that will help. > > Possibly I can contribute to improve documentation by carefull reading, > trying and so on > > Johannes > > Am 11.10.2010 um

Re: [Pharo-project] Pharo by Example has moved to github

>> Excellent, can I also push the Seaside Book there? > > If you want. Now I do not see the interest of git when we use it as svn. And > I would prefer to host the book on an inria server > because I know that this is backup by someboyd else than me. > and for a book I do not want to fork it (or p

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

> "Lukas" == Lukas Renggli writes: Lukas> 1. It is not easily understandable for newbies. Lukas> 2. It quickly leads to very unreadable, hard to understand and hard to Lukas> refactor code. Lukas> 3. It is very limiting in itself and quickly leads to other hacks Lukas> (like to replace sort b

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

I think this discussion has diverged a lot from the original question, which is to do with the compiler being too pedantic. #ifNotNil: and friends are the selectors of methods which just happen to give the compiler an opportunity for a nice optimization, in the case when the argument that follows

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

I am currently concerned with remote programming (debugger, browser, compiler e.t.c) in Pharo from one image (or environment) to another, so that this infrastructure can be used in the field of autonomous robotics to ease the development cycle. So we should definitely exchange ideas ! Cause there

Re: [Pharo-project] Another finalization concern: error handling

On 11 October 2010 18:23, Henrik Johansen wrote: > > On Oct 11, 2010, at 4:10 13PM, Schwab,Wilhelm K wrote: > >> >> I am far more worried about having multiple executors per object (when did >> p=malloc();free(p);free(p);free(p) become good style?) than I am about >> getting the finalizer proces

Re: [Pharo-project] Another finalization concern: error handling

Henry, Ok, what valid use of multiple executors have I missed? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johan...@veloxit.no] Sent: Monday, October 11, 2

[Pharo-project] how to get the diff on commit on the pharo source?

I would really like to have the same behavior than the squeak system ie having the source modification send to the list. I could not see how to set it up on squeaksource. May be this is not the same version running. Stef ___ Pharo-project mailing list

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

Nick, I'm certainly no expert on DST, but I will gladly help where I can. You're starting a PhD program? Is Stef your advisor? That would put you in good hands. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gfo

Re: [Pharo-project] how to get the diff on commit on the pharo source?

On 11 October 2010 17:49, Stéphane Ducasse wrote: > I would really like to have the same behavior than the squeak system ie > having the source modification > send to the list. I could not see how to set it up on  squeaksource. > May be this is not the same version running. It is disabled becaus

Re: [Pharo-project] how to get the diff on commit on the pharo source?

Maybe on a separate mailing list. Cheers, Alexandre On 11 Oct 2010, at 12:49, Stéphane Ducasse wrote: > I would really like to have the same behavior than the squeak system ie > having the source modification > send to the list. I could not see how to set it up on squeaksource. > May be this

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

On Oct 11, 2010, at 8:07 AM, Stéphane Ducasse wrote: > Hi guys > > there is a HUGE HUGE HUGE difference between > (1) namespace at the language level and we do not want that the way > german did it. Stéphane, Are you suggesting that the approach Germán Leiva demonstrated at ESUG last

Re: [Pharo-project] Another finalization concern: error handling

Meanwhile, i'll try to implement two test cases for WeakRegistryTest. One, should cover following: coll := OrderedCollection new. obj := Object new. wrapper := WeakArray with: obj. coll add: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with:

Re: [Pharo-project] Another finalization concern: error handling

Sig, The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. That way, whether they are taken down by an error doing what they are

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

2010/10/11 Peter Hugosson-Miller : > I think this discussion has diverged a lot from the original question, which > is to do with the compiler being too pedantic. > > #ifNotNil: and friends are the selectors of methods which just happen to > give the compiler an opportunity for a nice optimization,

Re: [Pharo-project] Another finalization concern: error handling

On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: Henry, Ok, what valid use of multiple executors have I missed? I described it earlier how the AXAnnouncements project uses this feature. Levente Bill From: pharo-project-boun...@lists.gforge.inria.fr

Re: [Pharo-project] Another finalization concern: error handling

Ok, I'll dig around for that and have a look. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [le...@elte.hu] Sent: Monday, October 11, 2010 12:31 PM To: Pharo-project@lists.gfo

  1   2   >