Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Fwd: do you have an idea how we could talk from pharo to vw?
by Stéphane Ducasse 10 Aug '10

10 Aug '10

This can be interested to other Smalltalkers :) Begin forwarded message: > From: Kris Gybels <kris-gybels(a)skynet.be> > Date: August 5, 2010 6:13:01 PM GMT+02:00 > To: Stéphane Ducasse <stephane.ducasse(a)inria.fr> > Cc: Andy Kellens <akellens(a)vub.ac.be>, Johan Brichau <johan.brichau(a)uclouvain.be> > Subject: Re: do you have an idea how we could talk from pharo to vw? > > A direct answer to your question where the code is: > > The code of STaPLe is in a SourceForge CVS repository, this page explains how to check out the repository or browse it via a web browser: http://sourceforge.net/scm/?type=cvs&group_id=96556 > > There are brief NOTES files explaining what additional things you need (SWI-Prolog) and how the code can be built if you would really want to try it out; but be warned, the last time I looked at it was in 2003 ... > > About the idea: > > I would suggest you start by using an existing distributed messaging framework to communicate between Pharo and VisualWorks. I don't know about any such frameworks, since I never needed one, but I'd be surprised if one for Smalltalk does not exist. ;) > > The only advantage I can immediately see to doing something similar to what I did with STaPLe is that you can eliminate the overhead of process switching and socket communication by running the two virtual machines in the same process. The essence of STaPLe is a small piece of C code that staples together the virtual machines of VisualWorks and SWI-Prolog by using their C foreign function interfaces. But except for the fact that they communicate through these foreign function interfaces and not through sockets, STaPLe does much the same thing as you would have to do for distributed messaging: it converts strings and numbers from one virtual machine to the other, makes proxies for objects so that they can be sent a message from the other side and so on. This creates a lot of overhead for each message send. I am not sure whether process switching and socket communication creates enough additional overhead to try to optimize it away. > > So: Try distributed messaging first. That way you don't need to do anything in C. If you find it is too slow for what you want to do, try to get rid of process switching and socket communication by using the foreign function interface way. If it's still too slow, then err ... I think the only option left is: run all your code in only one Smalltalk virtual machine ;)) > > Regards, > Kris. > > On 05 Aug 2010, at 11:47, Stéphane Ducasse wrote: > >> thanks! >> >> Stef >> >> On Aug 5, 2010, at 11:46 AM, Andy Kellens wrote: >> >>> Stef, >>> >>> I added Kris's new email address to this conversation. >>> >>> On 05 Aug 2010, at 11:45, Stéphane Ducasse wrote: >>> >>>> Hi kris >>>> >>>> how can I access the code of staple? >>>> >>>> Stef >>>> On Aug 5, 2010, at 10:48 AM, Andy Kellens wrote: >>>> >>>>> Hello, >>>>> >>>>> The trick with using VW as a DLL indeed seems a good idea. >>>>> While I also don't have a clue how this actually works, I believe Kris used it when he implemented StaPLe (a bridge between SWI-Prolog and VW). >>>>> You can probably find some example code on that project's website: http://staple.sourceforge.net/ >>>>> >>>>> Andy >>>>> >>>>> On 05 Aug 2010, at 10:42, Johan Brichau wrote: >>>>> >>>>>> Hm.... except the traditional unwanted xml-rpc communication, I would investigate the possibility to use Alien/FFI and talk to Visualworks as a dll. >>>>>> I seem to remember that Visualworks can be used like that, but I'm not sure. >>>>>> >>>>>> If that works, you can create a high-level communication layer that would make communication seamless. > >

1 0

MOChildrenShape
by Bergel, Alexandre 10 Aug '10

10 Aug '10

Hi Doru, In a form builder, should we have a rendering of the inner nodes at each = occurrence of a children shape? If there is no children shape in a form = builder, can the inner nodes be rendered? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 2

Orion Framework
by Laval Jannik 10 Aug '10

10 Aug '10

Hi guys, I publish a small description of Orion on moose website (http://). A tutorial is also available (For now it is small and maybe it has some english issues. I will improve it). Orion is a tool for reengineering, to simulate changes and compare their impact on multiple versions of software source code models. You can try it: ===== Gofer new squeaksource: 'Orion'; package: 'ConfigurationOfOrion'; load. (Smalltalk at: #ConfigurationOfOrion) perform: #loadDefault. ===== I am also available to answer your questions. Cheers, --- Jannik Laval

3 2

finder improvements
by Tudor Girba 09 Aug '10

09 Aug '10

Hi, I am working a bit on some enhancements for Moose Finder: - You can now extend it with new presentations by adding a method in the Finder with a pragma like: sourceTextIn: aComposite <presentation: 10> aComposite text title: 'Source'; titleIcon: MenuIcons mooseSourceText; display: [ :each | each mooseInterestingEntity sourceText ]; when: [ :input | (input mooseInterestingEntity class canUnderstand: #sourceText) and: [input mooseInterestingEntity sourceText notEmpty ] ] - I added icons for the default presentations (see attached picture) Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

2 2

moose-dev@iam.unibe.ch 47% OFF on Pfizer!
by moose-dev＠iam.unibe.ch 08 Aug '10

08 Aug '10

http://groups.yahoo.com/group/trevtourenn/message fburdung restloser Verantwortlichkeit nach oben, wobei niemand Autoritat Untergebenen gegenuber erhalt, der nicht selbst Besserkonner der betreffenden Arbeit ist. Im Verlaufe von zwei Jahren habe ich mich mit meiner {669 Aufbau der Bewegung} Ansicht immer mehr durchgesetzt, und heute ist sie in der Bewegung, wenigstens soweit die oberste Leitung in Frage kommt, bereits selbstverstandlich. Der sichtbare Erfolg dieser Haltung aber zeigte sich am 9. November 1923: Als ich vier Jahre vorher zur Bewegung kam, war nicht einmal ein Stempel vorhanden. Am 9. November 1923 fand die Auflosung der Partei, die Beschlagnahme ihres Vermogens statt. Dieses bezifferte sich einschlie.lich aller Wertobjekte und der Zeitung bereits auf uber hundertsiebzigtaus

1 0

help with increase/decrease on Mondrian using Glamour
by Felipe Ignacio Valverde Campos 08 Aug '10

08 Aug '10

hello people, someone knows how to do this actions (increase/decrease) on a Mondrian Pane using Glamour, something like this script with the button action | browser | browser := GLMTabulator new. browser column: #mpanel. browser actions: [:root| {GLMAction new title: 'increase'; action: [ ??? ]; "<-- what can i put here ?" icon: MenuIcons smallWindowIcon }]. browser transmit to: #mpanel; andShow: [:a| a mondrian painting: [:view | view nodes: (1 to: 10)]]. browser openOn: {}. i see the MOEasel code like reference, but it's using a MOCanvas and MORoot... so i don't know how to do same things with Glamour code... can i get the MOCanvas from "mondrian pane" ? can i put a MOCanvas on a Glamour pane ? something else in order to manipulate the size ? thanks ! -- http://www.dcc.uchile.cl/~fvalverd/public_key.asc Estudiante de Ingeniería Civil en Computación. Facultad de Ciencias Físicas y Matemáticas. Universidad de Chile.

2 3

nightly build based on released pharo 1.1
by Tudor Girba 07 Aug '10

07 Aug '10

Hi, As you might know, Pharo 1.1 has just been released. I updated hudson to build based on this version. Everything looks fine. Cheers, Doru -- www.tudorgirba.com "It's not how it is, it is how we see it."

2 3

dsm failing tests
by Tudor Girba 07 Aug '10

07 Aug '10

Hi, 4 DSM tests fail in the latest version: http://hudson.moosetechnology.org/job/moose-latest-dev/272/testReport/ I checked a bit, and: - testAllDirectCycles: it looks like the order of the detected direct cycles is not quite correct, but the content of these cycles is (so, in my image allDirectCycles first is packE and packF) - I could not figure out what the other problems are. Could we fix these? :) Cheers, Doru -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

2 2

epsilon parser not
by Tudor Girba 05 Aug '10

05 Aug '10

Hi, I went quickly through the PetitJava implementation and I stumbled across the keywords implementation. I would propose a simpler solution: keyword ^ (arrayOfKeywords inject: PPEpsilonParser new not into: [:p :key | p / key asParser ]) token trimBlanks . Now the question is if it makes sense to have a separate parser class equivalent to PPEpsilonParser new not. If yes, what would a good name be? Cheers, Doru -- www.tudorgirba.com "Speaking louder won't make the point worthier."

2 6

another speed improvement
by Tudor Girba 05 Aug '10

05 Aug '10

Hi, I committed another small change that has a significant impact on the speed of Groups and especially the Moose Finder. We used to have: RuntimeStorage>>elements ^self asArray Now we have RuntimeStorage>>elements ^elements In other words, we are not returning an Array but the original OrderedCollection. This makes up for a significant speed improvement when having large models. Tests are green, but if you encounter problems, please let me know. In any case, I noticed that we are actually using the storage of a group in a wrong way. We should always use the storage which is already a collection instead of directly using the entities of a group. Cheers, Doru -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev