Alex
I imagine that this is to avoid mistake like
Moose
Moose-X
Moose-Y
and that people do it
Moose-All
Moose-X
Moose-Y
If this is what you have in mind how would it work from a process
point of view
1- I create
Moose
2- I create
Moose-XXX
- wanring
3- remove/rename
Moose - Moose-All
Thanks for your feedback.
Result is displayed in the Transcript. Sorry to not have said it
before.
oh, I see. Yes, this seems to be a really useful feature!
What is the difference between storing the result via the History
button vs. Store result into classes. Then also the results of
The problem is that you cannot forbid that now.
Or do you? what is the impact of forbidden that now on existing code?
Stef
On Oct 12, 2008, at 11:19 AM, Alexandre Bergel wrote:
Let me put it in another way.
Is there a situation where a package named MyPackage should require
another package
On Oct 11, 2008, at 21:20 , Stéphane Ducasse wrote:
excellent!
I would be also curious about the size of the strings.
And yes
- we need to have a cleanup process as proposed/examplified by keith
For the default fonts: do we have a process to reload the non
default fonts?
no. But
On Oct 12, 2008, at 13:09 , Adrian Lienhard wrote:
On Oct 12, 2008, at 12:52 , Stéphane Ducasse wrote:
this is strange that certain strings are repeated 3 times.
Flaps are like drawers
This tool allows you
SUnit removing...
hm..
we can find out by looking where they are referenced. If
this is strange that certain strings are repeated 3 times.
Flaps are like drawers
This tool allows you
SUnit removing...
Stef
On Oct 12, 2008, at 12:22 PM, Alexandre Bergel wrote:
Excellent Adrian.
For String, a similar expression does it:
ByteString allInstances asSortedCollection: [ :e1
In Visualworks there is no dash convention, which is much better...
This might be interesting in the context of discussion:
We documented the package naming conventions for Seaside 2.9 here:
http://code.google.com/p/seaside/wiki/PackageNaming
The complete list of packages is documented
Excellent Adrian.
For String, a similar expression does it:
ByteString allInstances asSortedCollection: [ :e1 :e2 | e1 size = e2
size ]
ByteString allInstances inject: 0 into: [:sum :el | sum + el size]
The total amount of strings is 1,533,483 bytes
Interesting:
Let me put it in another way.
Is there a situation where a package named MyPackage should require
another package MyPackage-Foo.
As we experienced, this evil dependency brings inconsistencies when
saving MyPackage.
What would it a nice way to prevent such situation ?
I imagine that this
On Oct 12, 2008, at 12:52 , Stéphane Ducasse wrote:
this is strange that certain strings are repeated 3 times.
Flaps are like drawers
This tool allows you
SUnit removing...
hm..
we can find out by looking where they are referenced. If you open an
inspector and close all other windows that
2008/10/12 Adrian Lienhard [EMAIL PROTECTED]:
no. But I don't think we need them anymore, especially if we have FreeType
You may want to keep Accujen for special situation (embedded system
with ARM CPU) where freetype cannot be uses or is not appropriate.
Accujen is pretty readable and comes
It makes sense. But in that setting, creating a package named
'Seaside' and beginning to add some Seaside-... packages as required
would be disastrous. No? But maybe I am missing something here...
Cheers,
Alexandre
On 12 Oct 2008, at 11:46, Lukas Renggli wrote:
In Visualworks there is no
2008/10/12 Damien Cassou [EMAIL PROTECTED]:
On Sat, Oct 11, 2008 at 11:16 AM, Alexandre Bergel
[EMAIL PROTECTED] wrote:
I think this tool deserve to have an entry in ScriptLoader
Generating dev images takes me a lot of time. It seems pharo
developers are not interested in pharo-dev images
I am also interested in that for Moose.
Cheers,
Doru
On Oct 12, 2008, at 4:09 PM, Serge Stinckwich wrote:
2008/10/12 Damien Cassou [EMAIL PROTECTED]:
On Sat, Oct 11, 2008 at 11:16 AM, Alexandre Bergel
[EMAIL PROTECTED] wrote:
I think this tool deserve to have an entry in ScriptLoader
Would it make sense then, to use Accujen as default? (Comparing the
two, I actually also prefer Accujen compared to Accuny. I just chose
the latter because it is currently the default code, menu, and list
font)
Adrian
On Oct 12, 2008, at 15:55 , Stéphane Ducasse wrote:
Yes!
Stef
no.
Just a point of explanation.
For pharo we want to have one image (one click) with all the dev tools
listed on the web-page of damien.
Then this image will be based on a core image and with tools
integrated (minimal number of class
extensions).
One of the reasons we asked damien not to do a
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
but UIManager
Tx
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Alexandre Bergel writes:
You should continue to produce your dev image.
I have seen a lot of people using it. Really.
I'm using the dev image. Both for pharo and Squeak 3.10.
Bryce
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
I'm rather curious now about how you manage Pharo. I took a look
at http://code.google.com/p/pharo/wiki/HowToContribute and
wondered what happens after that. I now imagine it involves
ScriptBuilder building the update, and then something uploading
it. What is the mechanism?
ok so the
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: October 12, 2008 9:29:18 PM CEDT
To: [EMAIL PROTECTED]
Subject: food for thoughts :)
You are not allowed to post to this mailing list, and your message has
been automatically rejected. If you think that your messages are
being rejected
Hi
to my stupefaction I discovered that the classVariables of a class are
not the same as the ones of its metaclass.
TheRoot classVarNames ~= TheRoot class classVarNames
Does any body have some ideas why this is like that?
For me this is a conceptual bug.
Stef
Stéphane Ducasse wrote:
I lukas I see that you group together all the tests and I would prefer
to have test associate with the package they test.
stef
Traditional PackageInfo users are expected to use the standard
implementation or roll their own, for each package that needs a custom
MC1.5+ Comes with a version of PackageInfo that has the notion of
package types. Predefined package types that you can make use of through
a simple dot suffix package name.
Dot suffixes are traditionally used for branches. We use them
extensively in Seaside.
Lukas
--
Lukas Renggli
Keith
the problems with such approaches is that each of these nice little
extensions will break the
analysis tools we are developing. I would prefer a good and stable
solution
over everybody can hack its own.
I want some invariants on top of which we can build other tools.
Stef
On Oct 12,
Maybe, one easy step to make MC simpler, is to remove (sub)categories
in packages. In that case, two packages, 'Moose' and 'Moose-Test' will
be completely unrelated.
Cheers,
Alexandre
On 12 Oct 2008, at 22:20, Stéphane Ducasse wrote:
Keith
the problems with such approaches is that each
Stéphane Ducasse wrote:
Keith
the problems with such approaches is that each of these nice little
extensions will break the
analysis tools we are developing. I would prefer a good and stable
solution
over everybody can hack its own.
I want some invariants on top of which we can build other
Dot suffixes are traditionally used for branches. We use them
extensively in Seaside.
I dont think you do, are you telling me that he package Seaside2.8a1
has a branch called .8a1
Yes, that's the 2.8 branch. Up to 2.8 every version had its own branch.
There are smaller examples in the
28 matches
Mail list logo
