- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Bulk] Re: Fwd: Fwd: Debris' Quuve - Technologies used
by stepharo April 22, 2015

April 22, 2015

thanks for the explanation. Le 22/4/15 08:41, Cameron Sanders via Pharo-users a Ã©crit :

1 0

Re: [Pharo-users] Fwd: Fwd: Debris' Quuve - Technologies used
by Mariano Martinez Peck April 21, 2015

April 21, 2015

Yanni, please find my answers below. On Thu, Apr 16, 2015 at 10:57 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Wed, Apr 15, 2015 at 9:53 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > >> >> On Apr 15, 2015, at 8:01 PM, Cameron Sanders via Pharo-users < >> pharo-users(a)lists.pharo.org> wrote: >> > >> > Sure, I am happy to share. We are to the point that we need to get >> people interested in this platform; one thing we offer is a source license >> and therefore we need to document things that we have not yet documented. >> > >> > So please, fire away any questions. >> >> Are there any instances of Magritte framework that are not an instances >> of a custom subclass? (Did you have to subclass everything?) >> > > No, we did not have to subclass everything. But quite some. For example, > the components, yes, we have to subclass them all. The main reasons are > more or less these: > > 1) We want everything to be ajaxfied (so every single component needed to > be rewritten for AJAX) > 2) We want all our components to use Bootstrap layout > 3) We want components/descriptions/renderes/etc that better fit our own > needs > 4) We needed more hooks > > The only part that we did subclass everything is the components. Then we > have subclasses some descriptions but not all. We also have some special > descriptions. > > In addition, we have subclassed: > > - Memento: to provide extra hooks.... > - StringWriters: mostly to change the way we print floats, dateandtime, > dates, etc. > - TableRenderer: because we have 2-columns and 1-column type of form (and > to layout these forms using Bootstrap) > - FormDecoration and ValidationDecoration: to provide ajax and bootstrap > - DescribedColumn, CommandColumn, etc: we have lots of subclasses to > specify and improve our magritte reports > - other... > > >> >> What pushed you toward custom subclasses? Was the properties dictionary >> not sufficient for extending the object state variables, or was it a >> speed/performance issue? Would refactoring the Magritte classes to have >> various hook methods allowed you to avoid making custom subclasses? (I >> found that it was Twitter Bootstrap which drove the need for subclassing >> the framework, whereas native HTML would have been adaptable to Magritteâs >> needs). >> > > We DO extend some of Magritte superclasses using extension methods that > use the properties. We have quite some properties extended that way. > However, many other places we need to change the way things are displayed, > or arranges, or provide more hooks, to better fit our need etc. In that > case, just using properties is not enough. > Yes, if we would have had more hooks, we likely would have need to > subclass less. But not everything. We think Magritte was easy enough to > extend as is. Another thing we found is that sometimes is a bit hard to > agree on what is needed for all magritte users. So fully refactoring > Magritte may affect other developers or other use-cases of Magritte. > > >> >> Did you use the OneToOne and OneToMany relationship descriptions by >> subclassing, or did you create entirely new ones? >> >> > We have subclasses those. Why? Because we found out that it asks the > #optionsAndLabels quite a lot of times when it is not really necessary. For > example, to view an object, it needs to send #optionsAndLabels just to then > search the label for an specific option.... So we have created our own > "lazy" subclass of those 2 were #optionsAndLabels are computed as much > lazy/late as possible AND we can also plug a #getLabelClosure which avoids > getting #optionsAndLabels just for that... > > In addition to this, we have some special components (for example one that > uses autocomplete) and so the combination of lazy descriptions + > autocomplete component is very useful for long lists. > > >> What are some statistics on your model - e.g. number to classes? average >> (mean/median/mode) number of attributes/methods per class? average depth of >> the class hierarchy? >> >> > We'll have to get back to you on that one -- if we ever count them... > > > Do you translate/map the âSmalltalkâ query blocks for GemStone to get >> better speed, or is this unnecessary? >> >> > Yes. But only in a few places. We have currently 3 or 4 places where we > have indexes in GemStone collections. So what we did is that we have a > QueryBuilder strategy, with 2 subclasses, one for Pharo and one for > GemStone. And a singleton #current. Each class knows how to answer the > query closure for a particular query. It simply answers the closure we then > pass to the #select:. GemStone one will answer the { } one. > > > >> Do you use Magritte descriptions to tag things for indexing on GemStone? >> Or, do you just manually create indexes on GemStone as necessary (e.g. via >> install code that encapsulates knowledge of where to index, or does the >> system automatically raise flags when indexing is needed). >> > > The latter. We do not use Magritte here. > > >> >> From various postings, I gather you have a lot of data to process. Do you >> have any numbers like: >> - total number of objects in the system >> > > This is tricky, because it really depends on the advisory firm or the > researcher. Quuve is deployed for each customer. So the size really really > varies. > > >> - biggest collection, typical collection size >> >> > Right now for example we are dealing with storage of fundamental data of > companies (for research) , and prices... some collections have a few > million objects. What is important is that you must analyze which > collection class to use. Best (from our point of view) is one that supports > both, RC and Indexes. Just in case you need any of those later. > > > -- Mariano http://marianopeck.wordpress.com

5 9

deploying a desktop GUI based image
by Sebastian Heidbrink April 21, 2015

April 21, 2015

Hi all! I asked this question on the Moose list already ,but it seems nobody can help me there. I would liek to deploy a pharo app based on Glamour and Roassal as a "hands on demo". I was told Damien's Pharo launcher is currently somehow the reference implementation for a "fullscreen" pharo application. The pharo launcher is SPEC based and this provides some functionality regarding that but Glamour doesn't. So I assume there must be a "general" way to do it. Unfortunately I am not able to tell the Galmour Browser to be "fullscreen" and i also want to make sure nobody is able to get access to the code or pharo related tools. Does anybody here have experience in that or has a link to a documentation regarding this? The only stuff Ia was able to find is seaside headless related deployment but nothing for UI based images. Thank you for any help! Sebastian

4 7

Pharo is too much fun!
by Sean P. DeNigris April 21, 2015

April 21, 2015

The problem with Pharo is sometimes it's too much fun to play with objects. I could've just renamed my 5 classes via copy/paste, but I couldn't resist... classes := Smalltalk organization classesInCategory: packageName. classes do: [ :cls | | newName | newName := newPrefix, (cls name allButFirst: oldPrefix size). (RBRenameClassRefactoring rename: cls to: newName) execute ] ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-is-too-much-fun-tp4820809.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

1 0

SDL2 and fork
by Matthieu Lacaton April 21, 2015

April 21, 2015

Hello everyone, I tried to use the SDL2 binding to Pharo to create a very basic 2D application (just some sprites and events) and it worked great. The issue I have is that when I start my application, as long as I have an active SDL window, I can't use my Pharo image anymore (it freezes). To solve this problem I tried opening my application in another thread by doing so : [ (MyApplication new) start. ] forkAt: Processor lowestPriority. (If I don't chose a low priority it changes nothing) The problem is that even if it kind of works, it is really slow and it slows my whole operating system as well (I use windows XP) How can I fork more efficiently or open a SDL window without losing control of my image ? Thanks, Matthieu

8 25

[ANN] ArchLinux pharo-vm / pharo-launcher packages
by Laurent Laffont April 20, 2015

April 20, 2015

Hi ArchLinux users, you can now install pharo vm on Arch with: $ yaourt pharo-vm-latest then $ pharo /path/to/your/image There's also a pharo-launcher package that depends on pharo-vm: $ yaourt pharo-launcher then $ pharo-launcher or use your favorite desktop main menu and click on the Pharo icon AUR entries: https://aur.archlinux.org/packages/pharo-vm-latest/ https://aur.archlinux.org/packages/pharo-launcher/ PKGBUILDs are versionned on https://github.com/lolgzs/pharo-aur Thanks for testing ! Regards, Laurent

7 11

Polygons + Skybox in woden?
by Lusa Nicolas April 20, 2015

April 20, 2015

Hello, I am Nicolas Lusa from university of Lugano and I am working on my master thesis with the supervision of Yuriy Tymchuk. Right now I am working with woden and I am trying to build polygons. Question1: Is it possible somehow to build polygons in woden? If not: I know woden is based on OpenGL and I also know that in OpenGL is possible to draw polygons with GL_POLYGON and a given array of points. Question2: How could I use GL_POLYGON through woden for my purpose? Moreover, I would like to put some sort of skybox in my scene. Apparently it's not possible yet, so my question is how could I do that? Thanks in advance. Cheers. Nicolas

6 11

fluid dynamics fully in Pharo :)
by stepharo April 20, 2015

April 20, 2015

HoneyGinger is a fluid dynamics and visualization library which can simulate moves of liquid caused by obstacles and visualize refraction by estimating angles of water surface from distribution of pressure. https://www.youtube.com/watch?v=jl6OSWUXh14 Thanks Oda for this great demo.

1 0

exception handling problem when running tests in Nautilus
by Otto Behrens April 19, 2015

April 19, 2015

Hi, Thanks everyone for the new Pharo and all the work done. I like Spotter! I gave Pharo 4 a try today and ran into a problem with running tests in a TestCase (test class -> run tests). I just get the debugger popping up with WARequestContextNotFound. In the setUp of our test case, we call WACurrentRequestContext value, but handle the error when we do not have a context, for example: [ WACurrentRequestContext value. true ] on: WARequestContextNotFound do: [ :e | false ] This handler: "[ :e | false ]" is never called. What influences this is the exception handling in: AbstractNautilusUI >> #runTestsOfClass:notifying: Firstly, I think that it may be slighly better to call "e pass" or "e outer" in stead of "e defaultAction", as this would give another outer handler a chance to do something. The defaultAction is called when there are no more outer handlers anyway. After trying this, it did not help my cause. And I think that this is because the WACurrentRequestContext is a Notification and not an Error. I then replaced Exception with Error in the handler in AbstractNautilusUI. This seem to work. What also works is to completely remove the exception handling in AbstractNautilusUI >> #runTestsOfClass:notifying: What is a bit strange is the inconsistency in this exception handling when running a suite or an individual test. Perhaps this kind of code could be better on the TestSuite and not in the Nautilus UI? Can anyone please help? Should I be doing something else? Cheers Otto

1 0

[ANN] Pharo 4.0 is released!
by Esteban Lorenzano April 18, 2015

April 18, 2015

Please spread widely. Sorry for multiple posts. (this post can be see here: http://pharo.org/news/pharo-4.0-released <http://pharo.org/news/pharo-4.0-released>) Dear World, Pharo 4.0 (http://www.pharo.org) is here. Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback. Many things have changed in Pharo. Here are some highlights: - Inspector/Playground/Spotter are new moldable development tools for inspecting, coding and searching objects. - Slots model instance variables as first class entities and enable meta-programming on this level. - ShoreLine reporter introduces a way to report system errors and collect statistics, that we will use for future improvements - Dark theme. These are just the more prominent highlights, but the details are just as important. We have closed 1697 issues in Pharo 4. Take a moment to go through a more detailed recount of the progress: https://github.com/pharo-project/ChangeLogs/blob/master/Pharo40ChangeLogs.md Pharo is improving on many fronts, but one of the most prominent changes is the addition of moldable tools for inspection and search. These tools provide extension mechanisms that allow every object to define ways in which it can be understood effectively. To provide an idea of the impact of the already existing extensions, the map below shows the Pharo classes grouped in packages, highlighting in red those parts of the system that have at least one such custom view coming with the main distribution. The spread of these extensions shows that moldability is powerful mechanism that can be used in many contexts. Remember that Pharo is your platform. We thank all the contributors of this release: Clara Allende, Jean-Baptiste Arnaud, Jean-Christophe Bach, Philippe Back, Clement Bera, Alexandre Bergel, Torsten Bergmann, Vincent Blondeau, Noury Bouraqadi, Santiago Bragagnolo, Johan Brichau, Sven Van Caekenberghe, Damien Cassou, Nicolas Cellier, Guido Chari, Dimitris Chloupis, Andrei Chis, Ben Coman, Bernardo Contreras, Tommaso Dal Sasso, Jan Van De Sandt, Christophe Demarey, Sean DeNigris, Marcus Denker, Martin Dias, Stephane Ducasse, Stephan Eggermont, Luc Fabresse, Johan Fabry, Hilaire Fernandes, Jerome Garcia, Tudor Girba, Thierry Goubier, Jigyasa Grover, Kris Gybels, Norbert Hartl, Dale Henrichs, Pablo Herrero, Nicolai Hess, Pavel Krivanek, Juraj Kubelka, Jan Kurs, Laurent Laffont, Jannik Laval, Kevin Lanvin, Max Leske, David Lewis, Diego Lont, Esteban Lorenzano, Tim Mackinnon, Attila Magyar, Esteban Maringolo, Stefan Marr, Max Mattone, Martin Mc Clure, Eliot Miranda, Alain Plantec, Guillermo Polito, Damien Pollet, Stefan Reichhart, Mark Rizun, Udo Schneider, Ignacio Sniechowski, Henrik Sperre Johansen, Igor Stasenko, Aliaksei Syrel, Ciprian Teodorov, Camille Teruel, Sebastian Tleye, Yuriy Tymchuk, Peter Uhnak, Andres Valloud, Sven Van Caekenberghe, Thomas Vincent, Jan Vrany, Martin Walk, Richard Wettel, Dmitri Zagidulin And all those who contributed indirectly, by reporting bugs, participating in discussion threads, providing feedback... Pharo 4.0 is another big step. And, the best is yet to come. Enjoy! The Pharo Team

16 16