I'm only an occasional reader here, but have noted (due to all of the reports
that bugs have been moved) that the bug database has moved.
It's very nice that I'm offered a link to view the status on the new fogbugz
site.
But how do I get an account? I can't view anything without logging in.
Two things make a class abstract.
One is that it has methods that a subclass must override — that is captured by
#hasAbstractMethods.
The other is that the class cannot be instantiated — normally because it has
overridden new.
It can be the case that an abstract class defines only CONCRETE
Without knowing what you are trying to accomplish, I have to bee too critical,
but have you though about doing something much simpler, using say the state
patterns, and delegating this method to another state object.
I'm particularly scared by the idea that the same object will have two
On 20 Jan 2012, at 07:31 , Bernardo Ezequiel Contreras wrote:
try
Smalltalk vm version
This just answers 'Pharo1.3', which is not surprising, since Smalltalk vm ==
SmalltalkImage current.
SystemVersion current version answers the same string.
On the latest Jenkins build, found from the
Teaching a class of novices, it's not surprising that someone tried Collection
new. What was surprising is that this got the VM is a loop of some kind, with
emergency stack dumps and so on.
Here is my reply:
On 30 Jan 2012, at 01:18 , Xingzhi Harry Pan wrote:
...it's pretty innocent:
Hmm, is this really right? I'm used to seeing Error in printString ...
On 30 Jan 2012, at 11:12 , Milan Mimica wrote:
On 30 January 2012 19:31, Andrew P. Black bl...@cs.pdx.edu wrote:
But I don't understand the root cause. Printing eventually sends do:, which
is self
The latest COG VM, pointed to from the Pharo-project download page,
CogVM-*-13307.zip, seems to be a little unstable. Many students have been
reporting that it just hangs while doing nothing more than editing (not saving)
text, and I have seen long hangs while doing trivial things — these
On 17 Aug 2011, at 14:24 , Igor Stasenko wrote:
yes.. except one thing: since contexts are allocated on heap, it means
more work for GC,
then it explains that it degrading linearly.
Andrew, can you play with GC parameters, like increase number of
allocations between incremental GCs etc?
On 17 Aug 2011, at 13:45 , Stéphane Ducasse wrote:
I prefer execute :)
because evaluate looks like you don't run fast and generate possibly assembly
on the fly.
I stopped long time ago to use evaluate because people also think that
Smalltalk is slow because of that evaluation
I'm
I was looking at some old slides of Joe Armstrong on Concurrency-orinted
programming. He set the following challenge:
Put N processes in a ring:
Send a simple message round the ring M times.
Increase N until the system crashes.
How long did it take to start the ring?
How long did it take to
Is there any documentation?
Andrew
On 17 Nov 2009, at 03:46, Alexandre Bergel wrote:
I recommand you to give a try at Mondrian.
http://www.squeaksource.com/Mondrian.html
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
I was recommending to a student that they look at Ned Konz's
Connectors package to help with a drawing project. I eventually
tracked downa fairly recent version in a SqueakSOurce project or
mine ... but it's very Squeak dependent.
Specifically, it has dependencies on:
Can someone please explain to me how to run code critic on a single
class or a single package?
I managed to run it (overnight) on Smalltalk. It found 70189 problems,
many of them jaw-dropping. But I would like to focus it on my code!
RIght on both counts. sameElements: is in RoelTyper
On 26 Oct 2009, at 07:56, Nicolas Cellier wrote:
This is exactly SequenceableCollection#hasEqualElements:
I have no #sameElements: in core.
Nicolas
hasSameSequenceOfElements: is still a better name than hasEqualElements:
For traits, requirements were programmatically inferred instead of
using #explicitRequirement.
In the original traits implementation, inference of requirements was
necessarily incomplete. For example, if a method says
self add: x
or
self class new: n
we would infer
I agree with Nicolas, but I think that it's really important that we
have this discussion, reach a consensus, and them implement it!
That's why I posted the message here rather than just posting a bug
report.
There used to be a method called hasSameElementsAs: (now called,
inexplicably,
The golden rule of hashing is (a = b) = (a hash = b hash). Right?
Look at this:
(1 to: 10) species --- Array
#(1 2 3 4 5 6 7 8 9 10) species --- Array
(1 to: 10) = #(1 2 3 4 5 6 7 8 9 10) --- true
However,
(1 to: 10) hash = #(1 2 3 4 5 6 7 8 9 10) hash --- false.
I believe that
I've been playing with a Morphic implementation of Joe the box for
an intro programming course. It shouldn't be hard, right?
The problem is rotation. It's easy to rotate a polygon morph, but I
can't get a TextMorph (for the name) to rotate and stay centered. My
next attempt (attached),
Inspectors on an object foo say foo on NewInspector in the title.
They should just say foo. Workspaces say Shout Workspace; that's
an implementation detail.
I put a changeset in the bug database to fixes these annoyances.
(Issue 1245)
Andrew
I just committed (with much help from Stéphane) my first contribution
to Pharo!
Cleanup of Deprecation
Status:
Fixed
Owner:
Milestone-1.0
Submitted a bunch of small fixes that make the use of deprecation
uniform across Pharo. The
changes are mostly to the wording of the deprecation
I just submitted a fix, mostly internal to the MC GUI.
Log messages are now called log messages, uniformly.
Also, when asking MC to remove a required package, the dialog now asks
the user to select only from the presently required packages, not
every package in the system.
The package is
Ideally, what I think we want is for all of the packages to be written
atomically.
However, that is something that MC does not currently know how to do.
Next best would be to collect all of he log messages ahead of doing
any of the writing to the repository.
That would also require some
.
Prof. Andrew P. Black
Department of Computer Science
Portland State University
Oregon, USA
http://www.cs.pdx.edu/~black
Telephone: +1 503 725 2411
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr
23 matches
Mail list logo
