- Pharo-dev - lists.pharo.org

Re: [Pharo-project] CollabActive book :)

by Tudor Girba

Hi, I created the user with editor rights. I will send the password separately. For admins, here is how you create new users: 1. Go to: http://book.pharo-project.org/system/management/ 2. In the Users section add the user you want (the first input box) 3. In the dialog, make sure you add the groups you want to the user. Right now there are 2 groups: admin and editor. The editor is allowed to work on the content, the admin has additional rights in the system area. Cheers, Doru On 3 Apr 2010, at 16:49, StÃ©phane Ducasse wrote: > I tried to find how to add a new user but I failed. I will ask doru ;( > > Stef > > On Apr 3, 2010, at 2:38 PM, laurent laffont wrote: > >> So if you want to be an editor you are more than welcome! >> Just ask >> >> I ask :) >> >> Laurent Laffont. >> >> >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

April 3, 2010

Re: [Pharo-project] [Moose-dev] Re: Mondrian: present and future

by Tudor Girba

Hi Chris, The core of Mondrian has no relationship with OB. The rendering of Mondrian only depends on Canvas. By default, when you say "view open" a window with a canvas is created and the canvas is passed to Mondrian. Cheers, Doru On 3 Apr 2010, at 19:11, Chris Muller wrote: > HI Alexandre, what is the current status of Mondrian on Squeak? I've > always been intrigued by Mondrian, what would be the best approach for > getting it going on Squeak? > > I am mostly interested using Mondrians rendering and input-event > handling inside my own widgets, not OB or other windowing tools. How > hard would it be to extricate just the Form-drawing and > input-capability of the Mondrian core from the OB window widgetry that > seems to be included in the package (at least, the last time I > looked)? > > - Chris > > On Thu, Apr 1, 2010 at 3:15 PM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: >> Hi All, >> >> Just to give some news about Mondrian. Together with colleagues >> from Bern, >> Lille and Santiago, I have been working on this visualization >> engine for >> quite some times. Although it contains some important bugs (e.g., >> popupView) >> it is fairly stable and usable. The current version is 2.0-beta.7. >> >> Mondrian is slowly maturing. A short summary of the discussion I >> had with >> Doru and StÃ©phane today. >> Some of the features I would like to see in for Version 3.0 are: >> - scalable spring layout (also known as force based layout): this >> is a very >> simple and nice layout that produces amazing results >> - add layers: embedding a rendering or a part of it in a layer. >> Layers >> could then be iteratively activated and desactivared. The idea is >> to enable >> the construction of scripts in a very iterative and incremental way. >> - having a small core embeddable in your application >> - making Mondrian load graphiz scripts >> - having a better help system (Ã la ProfStef) >> - dedicated chapter for Pharo By Example Volume 2 >> - exporting as PDF >> - anti-aliasing >> >> This probably will not happen today or tomorrow, but I just feel >> necessary >> to share this roadmap with you. Some other features are wanted. >> Using Rome >> is one. Open GL is another. There are plenty of rooms for a very cool >> visualization engine. >> >> Probably during the holiday period I will consolidate the current >> version by >> fixing remaining bugs and produce 2.0. >> >> Bug tracker: http://code.google.com/p/moose-technology/ >> Web page: http://www.moosetechnology.org/tools/mondrian >> >> Let's render our dream! >> >> Cheers, >> Alexandre >> >> NB: sorry for this cross mailing list post. >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

April 3, 2010

Re: [Pharo-project] [Moose-dev] Mondrian: present and future

by Chris Muller

HI Alexandre, what is the current status of Mondrian on Squeak? I've always been intrigued by Mondrian, what would be the best approach for getting it going on Squeak? I am mostly interested using Mondrians rendering and input-event handling inside my own widgets, not OB or other windowing tools. How hard would it be to extricate just the Form-drawing and input-capability of the Mondrian core from the OB window widgetry that seems to be included in the package (at least, the last time I looked)? - Chris On Thu, Apr 1, 2010 at 3:15 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Hi All, > > Just to give some news about Mondrian. Together with colleagues from Bern, > Lille and Santiago, I have been working on this visualization engine for > quite some times. Although it contains some important bugs (e.g., popupView) > it is fairly stable and usable. The current version is 2.0-beta.7. > > Mondrian is slowly maturing. A short summary of the discussion I had with > Doru and StÃ©phane today. > Some of the features I would like to see in for Version 3.0 are: > Â - scalable spring layout (also known as force based layout): this is a very > simple and nice layout that produces amazing results > Â - add layers: embedding a rendering or a part of it in a layer. Layers > could then be iteratively activated and desactivared. The idea is to enable > the construction of scripts in a very iterative and incremental way. > Â - having a small core embeddable in your application > Â - making Mondrian load graphiz scripts > Â - having a better help system (Ã la ProfStef) > Â - dedicated chapter for Pharo By Example Volume 2 > Â - exporting as PDF > Â - anti-aliasing > > This probably will not happen today or tomorrow, but I just feel necessary > to share this roadmap with you. Some other features are wanted. Using Rome > is one. Open GL is another. There are plenty of rooms for a very cool > visualization engine. > > Probably during the holiday period I will consolidate the current version by > fixing remaining bugs and produce 2.0. > > Bug tracker: http://code.google.com/p/moose-technology/ > Web page: http://www.moosetechnology.org/tools/mondrian > > Let's render our dream! > > Cheers, > Alexandre > > NB: sorry for this cross mailing list post. > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

April 3, 2010

Re: [Pharo-project] FFI - structure pointer

by Schwab,Wilhelm K

Andreas, #getProcAddress: is a Smalltalk message, so it does not have a return type. It does return an ExternalData because it it ultimately calls <cdecl: void* 'FindSymbol' ( long char* ) > I had to create FindSymbol as a simply wrapper around dlsym() because the vm dies a quick death over (what I believe to be) linking hassles similar to recent problems in skype. Of course, I am referring the Linux vm or I would be calling GetProcAddress(). One thing that I considered is that the aspects of the ExternalData might be incorrect. The handle is an external address and type is an ExternalType that prints itself as void*. With many variations, if the call was made, the vm crashed. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Andreas Raab Sent: Saturday, April 03, 2010 11:54 AM To: The general-purpose Squeak developers list Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI - structure pointer On 4/3/2010 6:36 AM, Schwab,Wilhelm K wrote: > Andreas, John, anybody, > > I need to find the address of a "function" (it is in fact a global structure pointer somewhere in memory) and pass it to another function. > > Suppose the structure is called Type and the function allocate_one(). > I call the function something like > > allocateOne:type size:anInt > <cdecl: SomeOtherStruct* 'allocate_one' ( Type* long )> > > > but I am having an awful time getting the pointer to Type. Given that > dlsym() will return a pointer to it, how can I represent that in > Smalltalk? I have tried variations on > > "Indirectly call dlsym()" > address := Library default getProcAddress:'name_of_global_struct'. > > "try to create Type* from the resulting address" > type := Type fromHandle:address. > type := Type fromHandle:address getHandle. > type := ExternalData fromHandle:address type:Type externalType asPointerType. > > Something := Library default allocateOne:type size:2. > > and it either complains about bad arguments during the call or segment faults. Any ideas or similar examples? The return type of getProcAddress: is likely wrong. It should be declared to return void* which will cause it to return an ExternalData. With an ExternalData your second variant "Type fromHandle: data getHandle" will work. Cheers, - Andreas _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 3, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.0-10517-rc4dev10.04.1

by laurent laffont

With my VM on Archlinux 32 bits: 9176 run, 9156 passes, 20 expected failures, 0 failures, 0 errors, 0 unexpected passes. Stan, could you try using this VM ? To build it: wget http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz tar -xvzf Squeak-3.11.3.2135-pharo-src.tar.gz cd Squeak-3.11.3.2135-pharo-src/ mkdir build && cd build ../unix/cmake/configure --CFLAGS="-O2" make then ./squeak /path/to.image Laurent Laffont On Sat, Apr 3, 2010 at 6:23 PM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > hi Mariano, I get (Ubuntu 9.04) > 9176 run, 9152 passes, 20 expected failures, 4 failures, 0 errors, 0 > unexpected passes > > [1] : 'MCInitializationTest>>#testWorkingCopy' > [2] : 'MCSnapshotTest>>#testInstanceReuse' > [3] : 'TestIndenting>>#testCR2' > [4] : 'TestIndenting>>#testNewLineLeaveSpacesOnOldLine' > > ...Stan > -- > View this message in context: > http://n4.nabble.com/BetaTesting-ANN-Pharo-1-0-10517-rc4dev10-04-1-tp174923… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 3, 2010

Re: [Pharo-project] [OB] CodeCritics questions

by Lukas Renggli

See: http://www.lukas-renggli.ch/blog/ob-rb-3 As well: http://www.lukas-renggli.ch/blog/ob-rb-2 and http://www.lukas-renggli.ch/blog/ob-rb-1 On 3 April 2010 18:32, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi, > Â For Code Critics in OB users, if you select Refactor -> Code critics, > the lint checks starts automatically.... > > -But it seems to start in background on all image? (the toolbar says > "on Smalltalk") instead of the selected class category in the OB. It > is probably a bug? > -There is a percentage indicator but I don't know if refers to the > currently selected lint category or all lints plus transformations... > -It would be cool to start the lints on demand in a selected category? > What do you think? > > Cheers, > > HernÃ¡n > > -- > You received this message because you are subscribed to the Google Groups "OmniBrowser Development" group. > To post to this group, send email to omnibrowser-dev(a)googlegroups.com. > To unsubscribe from this group, send email to omnibrowser-dev+unsubscribe(a)googlegroups.com. > For more options, visit this group at http://groups.google.com/group/omnibrowser-dev?hl=en. > > -- Lukas Renggli www.lukas-renggli.ch

April 3, 2010

Re: [Pharo-project] FFI - structure pointer

by Andreas Raab

On 4/3/2010 6:36 AM, Schwab,Wilhelm K wrote: > Andreas, John, anybody, > > I need to find the address of a "function" (it is in fact a global structure pointer somewhere in memory) and pass it to another function. > > Suppose the structure is called Type and the function allocate_one(). I call the function something like > > allocateOne:type size:anInt > <cdecl: SomeOtherStruct* 'allocate_one' ( Type* long )> > > > but I am having an awful time getting the pointer to Type. Given that dlsym() will return a pointer to it, how can I represent that in Smalltalk? I have tried variations on > > "Indirectly call dlsym()" > address := Library default getProcAddress:'name_of_global_struct'. > > "try to create Type* from the resulting address" > type := Type fromHandle:address. > type := Type fromHandle:address getHandle. > type := ExternalData fromHandle:address type:Type externalType asPointerType. > > Something := Library default allocateOne:type size:2. > > and it either complains about bad arguments during the call or segment faults. Any ideas or similar examples? The return type of getProcAddress: is likely wrong. It should be declared to return void* which will cause it to return an ExternalData. With an ExternalData your second variant "Type fromHandle: data getHandle" will work. Cheers, - Andreas

April 3, 2010

Re: [Pharo-project] [For Testing] RC3 One-Click

by Mariano Martinez Peck

On Sat, Apr 3, 2010 at 1:42 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> > - There is a problem in the tests of RBInternalSpellChecker in Linux > >> > and > >> > Windows, when you are not connected to internet. There are 13 errors > >> > tests. > >> > The SpellChecker uses the MacOS library, but for Linux and Windows it > >> > uses > >> > its own. But...it needs to download the file. Thus, it fails if you > are > >> > off-line. The place is in > >> > RBInternalSpellChecker >> downloadData > >> > And of course, self url is > >> > 'http://www.lukas-renggli.ch/smalltalk/rb-spelling.dat'. > >> > As now with Metacello configurations, it is easy to select if you want > >> > to > >> > download the tests or not, I would put that file somehow in the image > >> > (part > >> > of the test package). The file is 2.1 MB on disk. > >> > But maybe there is a reason not to do this. Lukas ? > >> > >> The file contains a spelling-dictionary for platforms without a spell > >> checker primitive (Windows, Linux). If the file is in there, the spell > >> check does not try to download it. So maybe it would make sense for > >> the Metacello configuration to evaluate "RBInternalSpellChecker new" > >> to force the download of the dictionary and cache it next to the > >> image? > > > > Yes, that sounds ok. And then, I deliver the PharoDev image with that > file, > > isn't it ? > > Yes, you can, if you want to make it independent of the internet. > > Ok...done in ConfigurationOfRefactoringBrowser-MarianoMartinezPeck.22 (ConfigurationOfRefactoringBrowser project version: '1.3-baseline') load > The problem is that the wordlist cannot be reasonably integrated with > the source code. It grows the image and the package code unreasonably. > > yes, understandable. > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 3, 2010

Re: [Pharo-project] [For Testing] RC3 One-Click

by laurent laffont

> > > - In linux there are 2 failing test: > TestIdenting >> testNewLineLeaveSpacesOnOldLine > TestIdenting >> testCR2 > They are not new. I even try to ask help and Laurent too some time ago. I > would like someone to analyze them. If it is a problem of the test, I would > remove them. If there is nothing wrong with the test, I would try to analyze > how to fix it. > > These fails comes from the /FreeTypeBitBltSimulation patch ( http://lolgzs.free.fr/pharo/FreeTypeBitBltSimulation.1.cs) included in Exupery VM from pharo web site. That's why I've not included it in the VM source I've done. Laurent Laffont

April 3, 2010

[Pharo-project] CodeCritics questions

by HernÃ¡n Morales Durand

Hi, For Code Critics in OB users, if you select Refactor -> Code critics, the lint checks starts automatically.... -But it seems to start in background on all image? (the toolbar says "on Smalltalk") instead of the selected class category in the OB. It is probably a bug? -There is a percentage indicator but I don't know if refers to the currently selected lint category or all lints plus transformations... -It would be cool to start the lints on demand in a selected category? What do you think? Cheers, HernÃ¡n

April 3, 2010