February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to disable development tools on Pharo 1.3

by Noury Bouraqadi

Thanx Mariano On 30 janv. 2012, at 17:21, Mariano Martinez Peck wrote: > Some stuff I recover form Esteban and some old code: > > cleanUpEnvironment > Smalltalk cleanUp: true. > ScriptLoader new cleanUpForDesktopProduction. > > > cleanUpForDesktopProduction > "This is same as cleanUpForProduction, but it does not remove DejaVu fonts" > > > SmalltalkImage > checkChangesFileAvailability: false; > checkSourcesFileAvailability: false. > > "No user-interrupt-into-debugger" > UserInterruptHandler cmdDotEnabled: false. > "turn off shift-click editing" > StringMorph editableStringMorph: false. > "No halos, etc." > Morph cmdGesturesEnabled: false. > "No user commands invokable via cmd-key combos in text editor" > ParagraphEditor cmdKeysInText: false. > Editor cmdKeysInText: false. > > > > And then if you have a morphic app: > > > prepareMorph: aMorph > World color: Color lightGray lighter lighter. > World removeAllMorphs. > World layoutPolicy: ProportionalLayout new. > World > addMorph: aMorph > fullFrame: (LayoutFrame fractions: (0@0 corner: 1@1)). > aMorph bounds: World bounds. > aMorph sticky: true > > > > > > > On Mon, Jan 30, 2012 at 5:16 PM, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > I remember having seen some time in the past a menu that allows to shrink the image and disable the world menu. > But, I can't retrieve any thing related. > I don't care about the menu per se. I'd be happy with a message to send to some object that does the job. > > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > http://www.kroobe.com/profile/noury > > > Afin de contribuer au respect de l'environnement, > merci de n'imprimer ce courriel qu'en cas de necessite > > Please consider the environment before you print > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

Feb. 2, 2012

[Pharo-project] Question regarding LinkedList collect:

by Andreas Haufler (scireum GmbH)

Hi everyone, I'm a Pharo newbie with some knowledge about Smalltalk. Surfing through the code base I stumbled over the implementation of LinkedList collect: - Your're right, there is none, it's inherited by SequenceableCollection. Looking through this code, I discovered that it builds a LinkedList of the same size and then uses the at: and at:put: selector to copy the transformed values form the first list to the second. Knowing that at: and at:put: have O(n) complexity for linked lists, this makes collect: an O(n^2) operation. On the other hand, this could easily changed into O(n) by implementing collect: for LinkedList: collect: aBlock "Evaluate aBlock with each of the receiver's elements as the argument. Collect the resulting values into a collection like the receiver. Answer the new collection." | newCollection | newCollection := self species new. self do: [:val | newCollection add: (aBlock value: val)]. ^ newCollection I profiled this using: x := LinkedList new. 1 to: 10000 do: [:n |x add: n]. TimeProfileBrowser onBlock: [ x collect: [:i | i] ] and saw a improvement of: 795msec (old) vs. 6msec (new). I wonder therefore, if LinkedList is just seldomly used (in Java i.e. nearly all lists use ArrayList nowadays)? Or would the system benefit from this improvement? I could then look through the other methods (collect:from:to: et. al.) and provide a patch. best regards + thank's for creating such a beautiful system Andreas Haufler

Feb. 2, 2012

Re: [Pharo-project] Building a developer community

by Max Leske

Good idea! I don't think you can (at least not in a clean way). I'll see what I can find out and get back to you. Max On 02.02.2012, at 10:08, laurent laffont wrote: > http://www.slideshare.net/kohsuke/building-developer-community > > Slide 9 looks interesting (Thank you for downloading page). How can I do that with cmsbox / pharo website ? > > Laurent Laffont

Feb. 2, 2012

[Pharo-project] Building a developer community

by laurent laffont

http://www.slideshare.net/kohsuke/building-developer-community Slide 9 looks interesting (Thank you for downloading page). How can I do that with cmsbox / pharo website ? Laurent Laffont

Feb. 2, 2012

Re: [Pharo-project] Clickable Source Code

by Camillo Bruni

On 2012-02-01, at 21:36, Tudor Girba wrote: > Hi, > > On 1 Feb 2012, at 21:17, Camillo Bruni wrote: > >> >> On 2012-02-01, at 21:14, Tudor Girba wrote: >> >>> Hi, >>> >>> Sounds cool. This is since a long time on the wish-list of Glamour :): >>> http://www.moosetechnology.org/tools/glamour/Ideas >>> >>> Just a question. Does the implementation hardcode opening the browser? It would be cool to have it customizable such that it can be used in other contexts as well. >> >> right now I use TextAction which then dispatch over the current editor, so fairly flexible I'd say. > > Excellent. This is what I thought as well when I looked at it. This means that you fixed the missing method from the Editor, I guess :). > >>> Also, I would be interested in getting specific behavior on cmd+click, too. >> >> my goal would be to get some of the refactoring menus as context menus in there. > > Cool. Let me know if you get it done. I would like to integrate this widget in Glamour. have a look at the changeset in http://code.google.com/p/pharo/issues/detail?id=5233 best cami

Feb. 2, 2012

Re: [Pharo-project] keeping up with lively-kernel (morphic)

by Lawson English

Does Pharo use Morphic? Is there a conscious decision on people's parts to NOT try and keep the various flavors of Morphic compatible, or is it just "too hard," or that people don't care, or think it irrelevant? Some graphical frameworks manage to keep a centralized core of classes because they are created by one group of people for one language and then bindings ported to other languages. Morphic is unique in that it is being [re]implemented in 3 different languages: Self, Smalltalk (with several variations within that branch) and JavaScript. Is there any way, or even desire, to coordinate between the differing versions? L On 2/1/12 2:51 PM, StÃ©phane Ducasse wrote: > Hi lawson > > may I ask you how this information is relevant to pharo? > > Stef > > On Feb 1, 2012, at 8:38 PM, Lawson English wrote: > >> It seems to me that the most active place where development of Morphic is taking place is in the context of Lively Kernel. Is anyone tracking what the LK people are doing and seeing how it can be backported, or used to create a new version, or integrated with the current version of Morphic or Cuis, etc? >> >> >> Lawson >> > >

Feb. 1, 2012

Re: [Pharo-project] keeping up with lively-kernel (morphic)

by StÃ©phane Ducasse

Hi lawson may I ask you how this information is relevant to pharo? Stef On Feb 1, 2012, at 8:38 PM, Lawson English wrote: > It seems to me that the most active place where development of Morphic is taking place is in the context of Lively Kernel. Is anyone tracking what the LK people are doing and seeing how it can be backported, or used to create a new version, or integrated with the current version of Morphic or Cuis, etc? > > > Lawson >

Feb. 1, 2012

[Pharo-project] GL on fbdev (was: Re: [squeak-dev] Building Cog with vm-display-fbdev)

by Michael J. Zeder

thanks to the hint of Eliot, I did some code updates. fbdev module for Cog is now committed. One thing I'm playing around with, and I have questions about, is the following (Eliot suggested to post it here): > A project for supporting the openGL lib to render output to fbdev (like that: http://www.mesa3d.org/fbdev-dri.html) would need major efforts, right? As far as I understand linux graphics architecture, it should be possible to render directly to the framebuffer device (maybe by a memcopy from a "FBO": http://songho.ca/opengl/gl_fbo.html) > But my knowledge doesn't reach far enough to figure out, if, how, and where that could integrate with existing/emerging squeak/GL infrastructure... I don't know if that would be a project of major importance ;) but â as squeak's/pharo's future graphics architecture is currently under discussion â I think it should be considered, that there are many different backends... The reason I asked is, that I currently build me a tiny core linux system with a smalltalk user land. It does work and it is fun... So thanks for any feedback! I enjoy Smalltalk :) Cheers Michael Am 30.01.2012 um 18:54 schrieb Eliot Miranda: > Hi Michael, > > On Sun, Jan 29, 2012 at 1:12 PM, Michael J. Zeder <post(a)michael-j-zeder.de> wrote: > hi! > I changed inelegantly the configure script to get a vm-display-fbdev and... > ...came to understand, that there are more issues with Cog + fbdev (below is the make output). > > Now I wanted to put it in a general question: are there efforts to maintain the vm-display-fbdev for CogVM? I guess there is little need for it in general, but in some cases it is nice to have (for building embedded or tiny systems the linux framebuffer is nice; sleak, confless). > Can anybody help me? Thanks. > > The Cog VM is derived from Qwaq/Teleplace (a defunct company that developed Croquet for business). There the display system was extended for additional host window support. That support was implemented for vm-display-X11 and vm-display-null but not for vm-display-fbdev. You'll need to implement similar stubs that you'll find in the vm-display-null, since most of these primitives don't make sense/don't do anything in the context of fbdav (which takes control of the frame buffer and is hence always full-screen). When you've implemented the stubs please send me the code so I can implement. > > Doubtless you'll have worked out that you want to say "--with-vm-display-fbdev" to get that compiled in. > > HTH & good luck > Eliot > > > > Cheers! > > /bin/bash /home/mjz/Squeak/squeakvm/Cog/unixbuild/bld/libtool --mode=compile gcc -g -O2 -msse2 -D_GNU_SOURCE -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0 -msse -DLSB_FIRST=1 -g -O2 -msse2 -D_GNU_SOURCE -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0 -msse -DLSB_FIRST=1 -Wall -Werror -DHAVE_CONFIG_H -I/home/mjz/Squeak/squeakvm/Cog/unixbuild/bld -I/home/mjz/Squeak/squeakvm/Cog/unixbuild/bld -I/home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm -I/home/mjz/Squeak/squeakvm/Cog/platforms/Cross/vm -I/home/mjz/Squeak/squeakvm/Cog/src/vm -I/home/mjz/Squeak/squeakvm/Cog/unixbuild/bld -I/home/mjz/Squeak/squeakvm/Cog/unixbuild/bld -I/home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm -I/home/mjz/Squeak/squeakvm/Cog/platforms/Cross/vm -I/home/mjz/Squeak/squeakvm/Cog/src/vm -I/home/mjz/Squeak/squeakvm/Cog/platforms/Cross/plugins/FilePlugin -I/home/mjz/Squeak/squeakvm/Cog/platforms/Cross/plugins/B3DAcceleratorPlugin -I/home/mjz/Squeak/squeakvm/Cog/platforms/unix/plugins/B3DAcceleratorPlugin -c -o sqUnixFBDev.lo /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c > gcc -g -O2 -msse2 -D_GNU_SOURCE -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0 -msse -DLSB_FIRST=1 -g -O2 -msse2 -D_GNU_SOURCE -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0 -msse -DLSB_FIRST=1 -Wall -Werror -DHAVE_CONFIG_H -I/home/mjz/Squeak/squeakvm/Cog/unixbuild/bld -I/home/mjz/Squeak/squeakvm/Cog/unixbuild/bld -I/home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm -I/home/mjz/Squeak/squeakvm/Cog/platforms/Cross/vm -I/home/mjz/Squeak/squeakvm/Cog/src/vm -I/home/mjz/Squeak/squeakvm/Cog/unixbuild/bld -I/home/mjz/Squeak/squeakvm/Cog/unixbuild/bld -I/home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm -I/home/mjz/Squeak/squeakvm/Cog/platforms/Cross/vm -I/home/mjz/Squeak/squeakvm/Cog/src/vm -I/home/mjz/Squeak/squeakvm/Cog/platforms/Cross/plugins/FilePlugin -I/home/mjz/Squeak/squeakvm/Cog/platforms/Cross/plugins/B3DAcceleratorPlugin -I/home/mjz/Squeak/squeakvm/Cog/platforms/unix/plugins/B3DAcceleratorPlugin -c /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c -fPIC -DPIC -DPIC -o sqUnixFBDev.o > In file included from /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:39:0: > /home/mjz/Squeak/squeakvm/Cog/platforms/Cross/vm/sq.h:194:0: error: ignoring #pragma auto_inline off [-Werror=unknown-pragmas] > /home/mjz/Squeak/squeakvm/Cog/platforms/Cross/vm/sq.h:196:0: error: ignoring #pragma auto_inline on [-Werror=unknown-pragmas] > /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:474:1: error: initialization from incompatible pointer type [-Werror] > /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:474:1: error: (near initialization for 'display_fbdev_itf.winOpen') [-Werror] > /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:474:1: error: 'display_ioPositionOfScreenWorkArea' undeclared here (not in a function) > /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:474:1: error: 'display_ioSizeOfScreenWorkArea' undeclared here (not in a function) > /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:474:1: error: 'display_ioSetCursorPositionXY' undeclared here (not in a function) > /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:474:1: error: 'display_ioGetWindowHandle' undeclared here (not in a function) > /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:474:1: error: 'display_ioPositionOfNativeDisplay' undeclared here (not in a function) > /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:474:1: error: 'display_ioSizeOfNativeDisplay' undeclared here (not in a function) > /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:474:1: error: 'display_ioPositionOfNativeWindow' undeclared here (not in a function) > /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:474:1: error: 'display_ioSizeOfNativeWindow' undeclared here (not in a function) > /home/mjz/Squeak/squeakvm/Cog/platforms/unix/vm-display-fbdev/sqUnixFBDev.c:407:14: error: 'display_dndLaunchFile' defined but not used [-Werror=unused-function] > cc1: all warnings being treated as errors > > make[1]: *** [sqUnixFBDev.lo] Fehler 1 > make: *** [vm-display-fbdev.la] Fehler 2 > > > > Am 29.01.2012 19:31, schrieb Michael J. Zeder: >> hello everbody, >> >> I want to build the CogVM (latest revision from squeakvm.org/svn/branches/Cog) >> but with the vm-display-fbdev module (for linux framebuffer device) as default. >> >> Now I am a bit stuck in understanding the make process. Just leaving out the "--without-vm-display-fbdev" as argument to the configure script does not lead to it being included in the compile process. >> Also I don't find the exact location in the scripts, where to tell that the vm-display-fbdev should not only be included, but shall also replace the default display-X11-module. >> >> Thanks for your help, >> best regards >> Michael >> >> > > > > > > > > -- > best, > Eliot > >

Feb. 1, 2012

Re: [Pharo-project] Clickable Source Code

by Tudor Girba

Hi, On 1 Feb 2012, at 21:17, Camillo Bruni wrote: > > On 2012-02-01, at 21:14, Tudor Girba wrote: > >> Hi, >> >> Sounds cool. This is since a long time on the wish-list of Glamour :): >> http://www.moosetechnology.org/tools/glamour/Ideas >> >> Just a question. Does the implementation hardcode opening the browser? It would be cool to have it customizable such that it can be used in other contexts as well. > > right now I use TextAction which then dispatch over the current editor, so fairly flexible I'd say. Excellent. This is what I thought as well when I looked at it. This means that you fixed the missing method from the Editor, I guess :). >> Also, I would be interested in getting specific behavior on cmd+click, too. > > my goal would be to get some of the refactoring menus as context menus in there. Cool. Let me know if you get it done. I would like to integrate this widget in Glamour. Cheers, Doru >> Cheers, >> Doru >> >> >> On 1 Feb 2012, at 20:54, Camillo Bruni wrote: >> >>> hi everyone, >>> >>> Today I hacked the ST80 Styler to support clickable source code links: >>> >>> - clicking on a Class name opens a Browser >>> - clicking on a instVar shows al users of it >>> ... >>> >>> The current limitation is the mouse-handling. Right now I run the actions on normal >>> clicks, not really nice. I wish to only run an action on cmd-click (like in eclipse). >>> >>> However left / middle / right clicks are already handled high up in the morphic tree >>> to generate these mostly useless menues... >>> >>> So I wonder is there a way to only get register for ctrl-click / alt-click / cmd-click? >>> >>> best >>> cami >> >> -- >> www.tudorgirba.com >> >> "What we can governs what we wish." >> >> >> >> > > -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

Feb. 1, 2012

Re: [Pharo-project] Clickable Source Code

by Camillo Bruni

On 2012-02-01, at 21:14, Tudor Girba wrote: > Hi, > > Sounds cool. This is since a long time on the wish-list of Glamour :): > http://www.moosetechnology.org/tools/glamour/Ideas > > Just a question. Does the implementation hardcode opening the browser? It would be cool to have it customizable such that it can be used in other contexts as well. right now I use TextAction which then dispatch over the current editor, so fairly flexible I'd say. > Also, I would be interested in getting specific behavior on cmd+click, too. my goal would be to get some of the refactoring menus as context menus in there. > Cheers, > Doru > > > On 1 Feb 2012, at 20:54, Camillo Bruni wrote: > >> hi everyone, >> >> Today I hacked the ST80 Styler to support clickable source code links: >> >> - clicking on a Class name opens a Browser >> - clicking on a instVar shows al users of it >> ... >> >> The current limitation is the mouse-handling. Right now I run the actions on normal >> clicks, not really nice. I wish to only run an action on cmd-click (like in eclipse). >> >> However left / middle / right clicks are already handled high up in the morphic tree >> to generate these mostly useless menues... >> >> So I wonder is there a way to only get register for ctrl-click / alt-click / cmd-click? >> >> best >> cami > > -- > www.tudorgirba.com > > "What we can governs what we wish." > > > >

Feb. 1, 2012