Hi guys
Can we get playground not hidding the old workspace?
The textselection is awfull.
Why do we sacrifice what is working in Pharo?
Some keybindings are not working,
registerToolsOn: registry
"Add ourselves to registry. See [Smalltalk tools]"
"self registerToolsOn: Smalltalk tools"
registry register: self as: #playground
SmalltalkImage current resetTools is broken on Moose :(
Great!
Then why the syntax highlithging does not support correctly the display
of incomplete class names and selector?
I will really consider to ask the rmod team to make its own Moose build
with decent default
because this is each time the same story instead of having the time to
fix a problem (snapshotcello is not working with latest moose
then I lose times to fix the system to work as good as the default pharo).
Stef
Hi,
I have regularly a problem when exploring things in debugger/inspector. It raise an error. Here is the captured video: https://dl.dropboxusercontent.com/u/710942/pharo/moose-debugger-error.mov
It says errorSubscriptBounds: for MethodContext>>tempAt:
Is it known error? Can I avoid it?
Thanks,
Juraj
Hi guys
Snapshotcello and MooseReloader fails on
((ConfigurationOfMoose project version: #development) ignoreImage: true; record)
It takes ages.
Can somebody confirm that this is the same problem?
Stef
Hello, everyone.
I'm working on a builder for Voronoi diagram. Is there something which can help me to build the polygon shape for the element in Roassal 2 ? Thank you.
Best regards,
Natalia
My dear friends,
this may be an ugly question, but why CodeCity and Roassal3d are not cooperating. Maybe I’m just not able to see the significant differences, but for me as 3rd person it seems that Roassal3d is missing concrete functionality, like CodeCity’s awesome builder, and CodeCity is missing event handling, translucent colors, etc… Maybe we can merge efforts?
Uko
Snapshotcello is currently only partially useable for managing Moose versions.
It provides a snapshot of the loaded versions of all packages, but doesn't know
to which groups & projects they belong. By flattening that data, further
development becomes practically impossible. We notice that when bug fixes no longer
get propagated, or the number of snapshots gets impractically large. A new snapshot
would be needed for each fix in each of the dependencies. I consider storing snapshots in
a configuration not a good idea. A flattened snapshot is fine for producing a reproducible
load, and is valuable as a separate object.
In Seaside we noticed that referring to versions as #stable and #development
is not enough, we need to make explicit that it is the stable #release3 #release3.0
or #release3.1. Bugs are fixed in those releases, and no APIs are changed in
3.0/3.1.
Referring to #stable of Seaside in your configuration is a potential bug, as it
will lead to a different version, with a different API, getting loaded when Seaside 3.2
is released.
I expect most projects will be better off separating bug fixes from feature development.
Stephan