Hi,
I've finally removed OSProcess from Moose, starting with #1739…
I've changed both Verveinej and ZeroConf (hidden OSProcess dependency) use FFI instead,
that way you can load OSProcess XOR OSSubprocess based on your needs.
Peter
Hi!
Apparently, I have to open a playground to specify a page.
p := GTPlayground new.
p openOn: GTPlayPage new.
Is there a way to set a page without opening it?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
What is the purpose of that package? It seems to do some heavy stuff with code completion without giving a clue on how this all works :-(
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
I don't know who maintains CI for Moose.
Can you add "github*.zip" files to ignored files for the artifacts?
It is downloaded by Monticello and apparently it is preserved among the
saved artifacts, which is unnecessary.
Peter
Hi all,
I think I found a bug in RTGrapher: it does not seem to respect the minX: axis setting when that value is bigger than 0. For example:
| b ds |
b := RTGrapher new.
ds := RTData new.
ds points: #(2 3 4).
b add: ds.
b minX: 1.
b build.
^ b view
-> x starts at 0.
But if I set it to a negative number (e.g. -1) the x axis does start at that value.
This is a problem for me, because I have data e.g. between +-20 and +-30 and this just looks ugly:
Can this be fixed? Thanks in advance!
--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Hi,
I'm looking into removing OSProcess dependency from Moose.
Where can I get verveinej.sh and how do I use it?
Alternatively I would need to know how long it takes for the verveinej to
run… is it instant? Does it take some time (i.e. would it block the image?).
Thanks,
Peter
There seem to be significant differences in how chunk file format is
actually implemented. Does anyone know about a reader for ObjectStudio
.clsformat, or a generic one that can read multiple smalltalk formats?
Stephan
Hi,
I have just downloaded Pharo 5 but, when I try to follow the
instructions on the Moose site on how to install it on a fresh Pharo 5
image, I got this error:
Could not resolve: Phexample [Phexample-NikoSchwarz.57] in
/home/offray/Programas/Grafoscopio/Dev/Pharo5/package-cache
http://www.squeaksource.com/Moose ERROR: 'GoferRepositoryError: Could
not access http://www.squeaksource.com/phexample: ZnInvalidUTF8: Illegal
leading byte for utf-8 encoding'
I would like to release something using the last Pharo image instead of
my current one. How can I solve this problem?
Cheers,
Offray
> From: Esteban Lorenzano <estebanlm(a)gmail.com>
> Date: 12 May 2016 at 17:49:34 GMT+2
> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>, Pharo Development List <pharo-dev(a)lists.pharo.org>, ESUG Mailing list <esug-list(a)lists.esug.org>, Seaside - general discussion <seaside(a)lists.squeakfoundation.org>, Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org>, "Magritte, Pier and Related Tools ..." <smallwiki(a)iam.unibe.ch>
> Subject: [ANN] Pharo 5.0 released!
> Reply-To: "Magritte, Pier and Related Tools ..." <smallwiki(a)list.inf.unibe.ch>
>
> Hi,
>
> Please spread widely, and sorry for multiple posts.
> (this post can be see here: http://pharo.org/news/pharo-5.0-released)
>
> Dear World,
>
> The time has come for Pharo 5.0!
>
>
>
> This is our most significant release yet. Here are some highlights:
>
> - The PharoVM is now based on Spur, the new memory management, and it brings with it a 35% speedup!
> - A new unified foreign function interface (UFFI) replaced NativeBoost to provide a strong Spur-compatible framework for interfacing with the outside world.
> - The Glamorous Toolkit now includes the GTDebugger to offer a moldable infrastructure that allows the developer to customize the debugger deeply.
> - The underlying Reflectivity mechanism has reached maturity with multiple pieces coming together to empower developers to instrument their own systems. For example, we now have breakpoints implemented as just a simple extension of this mechanism.
> - QualityAssistant is now part of the image to provide live feedback during development.
>
> These are just the more prominent highlights, but the details are just as important. We have closed 2446 issues in Pharo 5. Take a moment to go through a more detailed recount of the progress: https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo50Change….
>
> While the technical improvements are significant, just think of getting 30% faster out-of-the-box, still the most impressive fact is that the new code that got in the main Pharo 5.0 image was contributed by 100 people. Together we have touched 43% of the classes, and 20% of the methods. The following visualization rendered with Roassal in Pharo 5.0 is dedicated to this effort. The picture shows the touched classes and packages in gray, the authors and the links to the changed classes in red, and, using an automatically generated visual id, you can spot authors that have worked on similar projects.
>
>
>
>
> Pharo is more than code. It is an exciting project involving energetic people. We thank all the contributors of this release:
>
> Abdelghani Alidra, Clara Allende, David Allouche, Nicolas Anquetil, Thibault Arloing, Jean Baptiste Arnaud, Mangesh Bendre, Clement Bera, Alexandre Bergel, Torsten Bergmann, Usman Bhatti, Vincent Blondeau, Johan Brichau, Camillo Bruni, Miguel Campusano, Damien Cassou, Nicolas Cellier, Danny Chan, Andrei Chis, Christopher Coat, Ben Coman, Bernardo Contreras, Gabriel Omar Cotelli, Tommaso Dal Sasso, Paul De Bruicker, Sean De Nigris, Christophe Demarey, Simon Denier, Marcus Denker, Martin Dias, John Dougan, Stephane Ducasse, Stephan Eggermont, Johan Fabry, Sergio Fedi, Cyril Ferlicot, Holger Hans Peter Freyther, Joshua Gargus, Tudor Girba, Thierry Goubier, Kris Gybels, Norbert Hartl, Thomas Heniart, Dale Henrichs, Nicolai Hess, Alejandro Infante, Henrik Johansen, Goran Krampe, Pavel Krivanek, Juraj Kubelka, Denis Kudriashov, Matthieu Lacaton, Laurent Laffont, Kevin Lanvin, Jannik Laval, Alexander Lazarević, Skip Lentz, Max Leske, Dave Lewis, Esteban Lorenzano, Sheridan Mahoney, Mariano Martinez Peck, Max Mattone, John McIntosh, Rene Meusel, Eliot Miranda, Henrik Nergaard, Marion Noirbent, Merwan Ouddane, Nick Papoulias, Nicolas Passerini, Alain Plantec, Guillermo Polito, Damien Pollet, Baptiste Quide, Andreas Raab (RIP), Alain Rastoul, Stefan Reichhart, Lukas Renggli, Mark Rizun, Michael Rueger, Valentin Ryckewaert, Ronie Salgado, Udo Schneider, Boris Spasojevic, Igor Stasenko, Roger Stebler, Serge Stinckwich, Aliaksei Syrel, Camille Teruel, Pablo Tesone, Yuriy Tymchuk, Peter Uhnak, Masashi Umezawa, Dion Stewart, Sven Van Caekenberghe, Jan Van De Sandt, Benjamin Van Ryseghem, Toon Verwaest, Franck Warlouzet.
>
> (If you contributed with Pharo 5.0 development in any way and we missed your name, please send us a mail and we will add you).
>
> Enjoy!
> The Pharo Team
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.list.inf.unibe.ch/listinfo/smallwiki
Hi all,
With the valuable support from Johan, I'm migrating my Grafoscopio
interactive notebook project to last Pharo 5 / Moose 6 and its getting
in a really good shape (see screenshot below). Now I would like to
migrate the auto-update functionality when a node is changed. When text
nodes is easy, but for code nodes, I need to know when a playground has
changed, to send the proper message to the tree, updating its contents.
How to know when a playground contents has changed?
Cheers,
Offray
