Hi Ben,
On Thu, Feb 6, 2014 at 9:19 AM, b...@openinworld.com wrote:
Clément Bera wrote:
Hello pharoers,
The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM
that some of you were interested in it, but unfortunately you were lacking
information about it.
I wrote a
2014-02-06 20:34 GMT+01:00 Sebastian Sastre sebast...@flowingconcept.com:
Thanks for this information.
Great post.
So larger images would be no problem? let's say growing to 900MB?
I wouldn't say no problem, I would say that images up to 1 Gb should be
usable and should behave much better
Sounds great!!!
Alexandre
Le 06-02-2014 à 11:48, Clément Bera bera.clem...@gmail.com a écrit :
Hello pharoers,
The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM that
some of you were interested in it, but unfortunately you were lacking
information about it.
I
Thanks Clement for the post and a big thank you to Eliot for Spur!
Can't wait for pharo 4 running on Spur-based Cog ;-)
Luc
2014-02-07 Clément Bera bera.clem...@gmail.com:
2014-02-06 20:34 GMT+01:00 Sebastian Sastre sebast...@flowingconcept.com
:
Thanks for this information.
Great post.
It is now showing all the packages.
It is cool for when you want to make slices in expert mode (aka with no dirty
packages)
But is it the default use case?
Ben
On 21 Jan 2014, at 15:26, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote:
It is now showing all the packages.
It is cool for when you want to make slices in expert mode (aka with no dirty
packages)
But is it the default use case?
It is very important: both Sven and Igor deem it as
On 21 Jan 2014, at 16:02, Marcus Denker marcus.den...@inria.fr wrote:
On 21 Jan 2014, at 15:26, Benjamin benjamin.vanryseghem.ph...@gmail.com
wrote:
It is now showing all the packages.
It is cool for when you want to make slices in expert mode (aka with no
dirty packages)
But is it
21 Jan 2014, at 12:03, Marcus Denker marcus.den...@inria.fr wrote:
This will simplify *a lot* to make a Slice fro syncing with Spec, too.
Can you expand please?
Because I have only seen the UI change, but I do not see where it can help :)
Thanks,
Ben
On 21 Jan 2014, at 18:32, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote:
21 Jan 2014, at 12:03, Marcus Denker marcus.den...@inria.fr wrote:
This will simplify *a lot* to make a Slice fro syncing with Spec, too.
Can you expand please?
Because I have only seen the UI change, but I do
… is not there anymore.
And Magritte-Morph requires it :(
my guess: I was another victim of Stef compulsion of giving us a better and
cleaning system :)
But it should be replaced by what?
Esteban
On 05 Jan 2014, at 11:30, Esteban Lorenzano esteba...@gmail.com wrote:
… is not there anymore.
And Magritte-Morph requires it :(
my guess: I was another victim of Stef compulsion of giving us a better and
cleaning system :)
The thing was that it had no state nor behaviour different to
On 05 Jan 2014, at 11:33, Marcus Denker marcus.den...@inria.fr wrote:
On 05 Jan 2014, at 11:30, Esteban Lorenzano esteba...@gmail.com wrote:
… is not there anymore.
And Magritte-Morph requires it :(
my guess: I was another victim of Stef compulsion of giving us a better and
cleaning
MAElementRow was still depending on RectangleMorph.
But it was more a problem of the #stable release: it was not updated.
Esteban
On 05 Jan 2014, at 11:42, Tudor Girba tu...@tudorgirba.com wrote:
Hi Esteban,
I fixed this issue in Magritte-Morph a long time ago when we ported Moose to
and you added a baseline 3.2 but not a version (not cool, doru, not cool :)
On 05 Jan 2014, at 12:07, Esteban Lorenzano esteba...@gmail.com wrote:
MAElementRow was still depending on RectangleMorph.
But it was more a problem of the #stable release: it was not updated.
Esteban
On 05 Jan
I added a development version to point to the baseline :)
Cheers,
Doru
On Sun, Jan 5, 2014 at 12:11 PM, Esteban Lorenzano esteba...@gmail.comwrote:
and you added a baseline 3.2 but not a version (not cool, doru, not cool :)
On 05 Jan 2014, at 12:07, Esteban Lorenzano esteba...@gmail.com
g
one of this days we should write the “metacello compendium”, and create
agreements in ways to do things :P
On 05 Jan 2014, at 12:41, Tudor Girba tu...@tudorgirba.com wrote:
I added a development version to point to the baseline :)
Cheers,
Doru
On Sun, Jan 5, 2014 at 12:11 PM,
anyway, I added a 3.2 version, so I can reference it in my projects (is
*really* not good to reference to a baseline of an external project in your
own… that just leads to a lot of pain :)
Esteban
On 05 Jan 2014, at 12:42, Esteban Lorenzano esteba...@gmail.com wrote:
g
one of this
Hi,
On Sun, Jan 5, 2014 at 12:44 PM, Esteban Lorenzano esteba...@gmail.comwrote:
anyway, I added a 3.2 version, so I can reference it in my projects
Thanks.
(is *really* not good to reference to a baseline of an external project in
your own… that just leads to a lot of pain :)
Not
On 05 Jan 2014, at 12:51, Tudor Girba tu...@tudorgirba.com wrote:
Hi,
On Sun, Jan 5, 2014 at 12:44 PM, Esteban Lorenzano esteba...@gmail.com
wrote:
anyway, I added a 3.2 version, so I can reference it in my projects
Thanks.
(is *really* not good to reference to a baseline of an
g
one of this days we should write the “metacello compendium”, and create
agreements in ways to do things :P
+ 1
I would love to have a list of metacello patterns.
Stef
On 05 Jan 2014, at 12:41, Tudor Girba tu...@tudorgirba.com wrote:
I added a development version to
tx
I will check.
Stupidly I was thinking that unload was removing classes from the system.
but (MCWorkingCopy forPackage: (MCPackage named: 'NautilusCommon')) unload.
does not remove the classes from the system
is it me or it was working?
It seems to work for me… I get a
Stupidly I was thinking that unload was removing classes from the system.
but (MCWorkingCopy forPackage: (MCPackage named: 'NautilusCommon')) unload.
does not remove the classes from the system
is it me or it was working?
Stef
On 24 Nov 2013, at 22:56, Stéphane Ducasse stephane.duca...@inria.fr wrote:
Stupidly I was thinking that unload was removing classes from the system.
but (MCWorkingCopy forPackage: (MCPackage named: 'NautilusCommon')) unload.
does not remove the classes from the system
is it me or it
El 04/10/2013 14:27, Camillo Bruni escribió:
What is that class? No comments, two single methods on Object that refer to it?
A WeakActionSequence is used as container for MessageSend's. It looks
like is not even really weak, there is no weakSubclass: definition...
You probably don't see
On Oct 4, 2013, at 7:28 PM, Camillo Bruni camillobr...@gmail.com wrote:
What is that class? No comments, two single methods on Object that refer to
it?
unknown… there are far too many event systems in the image…
Marcus
signature.asc
Description: Message signed with OpenPGP using
this related to the eventManager
triggerEvent: in Object
Stef
On Oct 5, 2013, at 9:44 AM, Marcus Denker marcus.den...@inria.fr wrote:
On Oct 4, 2013, at 7:28 PM, Camillo Bruni camillobr...@gmail.com wrote:
What is that class? No comments, two single methods on Object that refer to
it?
unknown… there are far too many event systems in the image…
On Oct 5, 2013, at 12:28 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote:
On Oct 5, 2013, at 9:44 AM, Marcus Denker marcus.den...@inria.fr wrote:
On Oct 4, 2013, at 7:28 PM, Camillo Bruni camillobr...@gmail.com wrote:
What is that class? No comments, two single methods on Object
What is that class? No comments, two single methods on Object that refer to it?
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 04 Oct 2013, at 19:27, Camillo Bruni camillobr...@gmail.com wrote:
What is that class? No comments, two single methods on Object that refer to
it?
If you remove it, the world as we know it will end !
Seriously, I've seen this before, I also asked the same question, but no one
seems to
This is a good question I was always wondering.
I think it is related to event triggered in DependentFields of Object. It
triggers several events.
Weak because somehow there are weak event handled without weak references,
probably due to the lack of ephemerons. (in some case the activation of the
For the Pharo Kernel I firstly in one job download the latest versions
of network packages and save it in a form of .st file. Then I load
them to the shrinked image.
Network packages:
#('Zinc-Resource-Meta-Core' 'Zinc-Character-Encoding-Core'
'Network-Kernel' 'Network-MIME' 'Network-UUID'
tx pavel
I will look at Ring too. Because I want to see why it is not a nice layer. But
I see because for packages there is probably a need to have it there.
On Oct 2, 2013, at 8:59 AM, Pavel Krivanek pavel.kriva...@gmail.com wrote:
For the Pharo Kernel I firstly in one job download the latest
[subject said it all].
Best
-Tobias
cmd f c
2013/9/8 Tobias Pape das.li...@gmx.de
[subject said it all].
Best
-Tobias
--
Best regards,
Douaille Erwan douaille.er...@gmail.com
On Aug 25, 2013, at 9:40 AM, Camille Teruel camille.ter...@gmail.com wrote:
On 24 août 2013, at 19:20, Camillo Bruni wrote:
We have now:
String #asClass
String #asClassIfAbsent:
String #asClassIfPresent:
I don't understand why we need this new way.
Is it just to avoid calling
On Mon, Aug 26, 2013 at 10:56 AM, Esteban Lorenzano esteba...@gmail.com wrote:
this was already discussed. With #asClass and relatives what you have is a
better abstraction jut because you are decoupled of Smalltalk globals, it
is not a big win now, but it open doors to better designs with
I do not see why
On Aug 26, 2013, at 11:14 AM, Damien Cassou damien.cas...@gmail.com wrote:
On Mon, Aug 26, 2013 at 10:56 AM, Esteban Lorenzano esteba...@gmail.com
wrote:
this was already discussed. With #asClass and relatives what you have is a
better abstraction jut because you are
Am 26.08.2013 um 10:56 schrieb Esteban Lorenzano esteba...@gmail.com:
On Aug 25, 2013, at 9:40 AM, Camille Teruel camille.ter...@gmail.com wrote:
On 24 août 2013, at 19:20, Camillo Bruni wrote:
We have now:
String #asClass
String #asClassIfAbsent:
String #asClassIfPresent:
On 2013-08-26, at 11:46, Norbert Hartl norb...@hartl.name wrote:
Am 26.08.2013 um 10:56 schrieb Esteban Lorenzano esteba...@gmail.com:
On Aug 25, 2013, at 9:40 AM, Camille Teruel camille.ter...@gmail.com wrote:
On 24 août 2013, at 19:20, Camillo Bruni wrote:
We have now:
It works the same way as the dictionary protocol with #at:
`#adsfasdf asClass` will signal an error, hence for compatibility you have
the *IfAbsent: protocols. Otherwise you simply cannot replace all the users
of `Smalltalk at:` and `Smalltalk globals at:` which is the long term goal.
On 26 août 2013, at 10:56, Esteban Lorenzano wrote:
On Aug 25, 2013, at 9:40 AM, Camille Teruel camille.ter...@gmail.com wrote:
On 24 août 2013, at 19:20, Camillo Bruni wrote:
We have now:
String #asClass
String #asClassIfAbsent:
String #asClassIfPresent:
I don't understand
the intent was to replace
Smalltalk at:
Smalltalk globals at:
idioms with shorter one, and get rid of referencing Smalltalk global.
The are not for solving future problems with introduction of environments.
And even if you introduce them, i still think you need a way to refer to
globals (they are
On 26 août 2013, at 13:31, Igor Stasenko wrote:
the intent was to replace
Smalltalk at:
Smalltalk globals at:
idioms with shorter one, and get rid of referencing Smalltalk global.
The are not for solving future problems with introduction of environments.
We want to get rid of Smalltalk
On 26 August 2013 14:34, Camille Teruel camille.ter...@gmail.com wrote:
On 26 août 2013, at 13:31, Igor Stasenko wrote:
the intent was to replace
Smalltalk at:
Smalltalk globals at:
idioms with shorter one, and get rid of referencing Smalltalk global.
The are not for solving future
... and Smalltalk should be renamed into Pharo anyway.
:-p
Phil
On Monday, August 26, 2013, Igor Stasenko siguc...@gmail.com wrote:
On 26 August 2013 14:34, Camille Teruel camille.ter...@gmail.com wrote:
On 26 août 2013, at 13:31, Igor Stasenko wrote:
the intent was to replace
https://pharo.fogbugz.com/f/cases/10583/Use-System-instead-of-Smalltalk-to-access-globals
On 2013-08-26, at 15:54, p...@highoctane.be p...@highoctane.be wrote:
... and Smalltalk should be renamed into Pharo anyway.
:-p
Phil
On Monday, August 26, 2013, Igor Stasenko
On Aug 26, 2013, at 3:54 PM, p...@highoctane.be wrote:
... and Smalltalk should be renamed into Pharo anyway.
:-p
:)
Camillo already wants systems.
Stef
On 26 août 2013, at 15:04, Igor Stasenko wrote:
On 26 August 2013 14:34, Camille Teruel camille.ter...@gmail.com wrote:
On 26 août 2013, at 13:31, Igor Stasenko wrote:
the intent was to replace
Smalltalk at:
Smalltalk globals at:
idioms with shorter one, and get rid of
Is it
asClass?
Stef
We have now:
String #asClass
String #asClassIfAbsent:
String #asClassIfPresent:
On 2013-08-24, at 17:55, Fernando Olivero fernando.oliv...@usi.ch wrote:
I prefer to evaluate
Smalltalk globals classNamed: #MyClass
Fernando
On Sat, Aug 24, 2013 at 11:57 AM, Stéphane Ducasse
On Aug 24, 2013, at 7:20 PM, Camillo Bruni camillobr...@gmail.com wrote:
We have now:
String #asClass
String #asClassIfAbsent:
String #asClassIfPresent:
Ok I found them. I was working in an older image
What was strange is that he method finder did not find it when I did #Point .
Point
Is there anybody using this class?
Stef
301 - 354 of 354 matches
Mail list logo
