Re: [Pharo-project] do you know what is this?

[Fernando Olivero]

NICE work Esteban!

Does the AthensQuartzSurface, support all Athens related code? (paths,
paints,etc..) I will be more than happy to move away from the software
rendering of the current cairo backend.

Fernando



On Tue, Apr 16, 2013 at 8:41 PM, Esteban Lorenzano  wrote:
> not to say about efficiency.
>
> I've been doing some cpu cycle tests.
>
> Rendering a 1600@1200 gradient to world canvas (repeat each 50ms):   ~90% cpu 
> consumption
>
> Same test, but sending it direct to window canvas using bridge: ~40% cpu 
> consumption
>
> so... we are in the good path :)
>
> Esteban
>
> On Apr 16, 2013, at 8:28 PM, Igor Stasenko  wrote:
>
>> On 16 April 2013 19:09, kilon  wrote:
>>> And you guys then say that pharo is not macos first citizen
>>>
>>> ha
>>>
>>> ha
>>>
>>> and
>>>
>>> ha
>>>
>>> I am a macos user , I love my imac and macos, but my vote goes to cross
>>> platform.
>>>
>>> Still another great library that is more than welcomed, definitely cant do
>>> any harm ;)
>>>
>>
>> By saying that we don't need Cairo on MacOS i meant following:
>>
>> Athens designed to support multiple backends.
>> It is out of question, that better to use most suitable backend,
>> available on current platform.
>>
>> But apart of it stays ObjC bridge. Which would allow us to speak with
>> ObjC-runtime
>> (and Mac VM using it) directly.
>>
>>>
>>>
>>> --
>>> View this message in context: 
>>> http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4681975.html
>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>

Re: [Pharo-project] [FYI] Athens tutorial

[Fernando Olivero]

NICE ! Excellent tutorial Igor.

But i was expecting the tiger at the end…with the song and everything.

Fernando

On Sun, Apr 7, 2013 at 9:07 AM, stephane ducasse
 wrote:
> Alex you can use it for real in roassal
> For the bootstrap
> - connection with TextMorph
> - reimplement all the drawOn: method
>
> stef
>
>
> On Apr 7, 2013, at 5:37 AM, Alexandre Bergel  wrote:
>
>> Really cool!
>> Works well!
>>
>> How far are we from bootstrapping?
>>
>> Alexandre
>>
>>
>> On Apr 3, 2013, at 8:07 PM, Igor Stasenko  wrote:
>>
>>> Hello, there
>>>
>>> i prepared a small tutorial for Athens, which i did today at PharoConf.
>>> But the code i did can be reused by non-participants of conference :)
>>>
>>> Here the instructions.
>>>
>>> Download Pharo 2.0
>>>
>>> wget -O - get.pharo.org | bash
>>>
>>> Run Pharo 2.0
>>>
>>> ./pharo-ui Pharo.image
>>>
>>> In a workspace, evaluate (line after line)
>>>
>>> Gofer it smalltalkhubUser: 'Pharo' project: 'Athens'; configuration; load.
>>>
>>> ConfigurationOfAthens loadVersion: '2.0'.
>>>
>>> Gofer it smalltalkhubUser: 'Pharo' project: 'Athens';
>>> package:'Athens-Tutorial'; load.
>>>
>>> AthensTutorial new openWithSpec.
>>>
>>>
>>> Took from here
>>> https://gist.github.com/SergeStinckwich/44ca34b54cde83b687a3
>>> (just removed duplicates ;)
>>>
>>> Thanks, Serge for compiling it down ;)
>>>
>>> Once you load the code and have window open, skip step one (you already did 
>>> it),
>>> and then just follow the steps by pressing doit button changing the
>>> code , pressing doit again , going forwards etc .. and playing with
>>> it.
>>> I put some comments there to serve as a small description/detail.
>>>
>>> Any feedback & help & contributions & improvements is welcome.
>>>
>>> P.S. if you get a DNU at step 30, enable Freetype in settings and try again.
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>
>

Re: [Pharo-project] Collect all references to AnObsoleteFoo

[Fernando Olivero]

Ciao Roberto,

Whenever you remove a class that is still referenced in the system, an
ObsoleteClass takes the place of the removed class. In the late-bound
spirit of Smalltalk, the system allows removing the classes and
dealing with the current references later.

If i may question the source of your problem: "a Dictionary
(containing receivers of method calls, i.e., classes) that I need to
serialize in a file (i.e., using Fuel)", are you sure you need to
serialize the actual classes? or just the names? or even a description
of the class within Ring? Think about what you are modeling with a
Dictionary that holds , and maybe try to
reify that concept.


Fernando




On Mon, Apr 1, 2013 at 9:58 PM, Max Leske  wrote:
> I've had the same problem just recently but am stuck in a bit of work right 
> now. I hope to elaborate at length tomorrow.
>
> Quick fix: if you *need* to serialize those classes, simply change the code 
> so that fuel serializes them. To fix obsolete classes you need to remove all 
> references to it, be it in a dictionary or in a compiled method where you 
> used the class name.
> Can you post the list of classes that are obsolete?
>
> Cheers,
> Max
>
>
>
> On 01.04.2013, at 16:51, roberto.mine...@usi.ch wrote:
>
>> Hi,
>>
>> I'm getting crazy about obsolete behaviors and any help here is really 
>> appreciated.
>>
>> In a nutshell, I have a Dictionary (containing receivers of method calls, 
>> i.e., classes) that I need to serialize in a file (i.e., using Fuel).
>>
>> Fuel returns an error in FLGlobalClassCluster>>#serializeGlobalClass:on: 
>> complaining that I'm trying to serialize an obsolete class.
>>
>> Now my question is, apart from executing this small piece of code...
>>
>> SmalltalkImage current fixObsoleteReferences.
>>   SystemNavigation new obsoleteBehaviors size > 0
>>   ifTrue: [ SystemNavigation new obsoleteBehaviors inspect.]
>>
>> …in which I discovered to have many obsolete references, how can I "browse" 
>> and eventually kill such references?
>>
>> For me the entire "behavior" of obsolete classes is obscure and I don't know 
>> how those classes are originated.
>> More important, I also don't know how to eliminate them.
>>
>> Thanks in advance,
>> Roberto
>>
>>
>
>

Re: [Pharo-project] Menu :)

[Fernando Olivero]

PUAJ!
Direct references to the World and its submorphs => secondary effects
Not popping the menu if the items are empty => lost visual feedback
etc…


On Mon, Mar 11, 2013 at 9:57 PM, Stéphane Ducasse
 wrote:
> I'm sure that we can do better...
>
>
> popUpAt: aPoint forHand: hand in: aWorld allowKeyboard: aBoolean
> "Present this menu at the given point under control of the given
> hand."
> | evt |
> aWorld submorphs
> select: [ :each | (each isKindOf: MenuMorph)
> and: [each stayUp not]]
> thenCollect: [ :menu | menu delete].
>
> self items isEmpty
> ifTrue: [^ self].
>
> (self submorphs
> select: [:m | m isKindOf: UpdatingMenuItemMorph])
> do: [:m | m updateContents].
> self layoutItems.
> "precompute width"
> self
> positionAt: aPoint
> relativeTo: (selectedItem
> ifNil: [self items first])
> inWorld: aWorld.
> aWorld addMorphFront: self.
> "Acquire focus for valid pop up behavior"
> hand newMouseFocus: self.
> aBoolean
> ifTrue: [hand newKeyboardFocus: self].
> evt := hand lastEvent.
> (evt isKeyboard
> or: [evt isMouse
> and: [evt anyButtonPressed not]])
> ifTrue: ["Select first item if button not down"
> self moveSelectionDown: 1 event: evt].
> self updateColor.
> self changed
>

Re: [Pharo-project] IslandVMTweaksTestCase and Memory corruption

[Fernando Olivero]

Island are part of the TeaTime implementation in Croquet. If the tests
are referring to that "Island" then why should Pharo include such
tests?

Fernando

On Thu, Feb 28, 2013 at 4:23 PM, Marcus Denker  wrote:
>
> On Feb 28, 2013, at 4:15 PM, Ciprian Teodorov 
> mailto:ciprian.teodo...@gmail.com>> wrote:
>
>
> No, I think that those tests should be shipped... And fix the VM to not 
> corrupt the memory. That's only in the case these test are wrote in pure 
> smalltalk. If they use ffi then yeah they should be removed
>
> They have primitives in methods for which the primitive was not written.
>
> On Feb 28, 2013 3:11 PM, "Marcus Denker" 
> mailto:marcus.den...@inria.fr>> wrote:
>
> On Feb 28, 2013, at 3:09 PM, Clément Bera 
> mailto:bera.clem...@gmail.com>> wrote:
>
> Hello,
>
> I was looking for VM tests in the Pharo image and I found the class 
> IslandVMTweaksTestCase. The strange thing is its comments :
> "Test case for some tweaks to the VM that Islands requires. These tests are 
> largely for documentation; with an un-tweaked VM, the tests mostly still 
> succeed, albeit with possible memory corruption."
>
> Does that really mean if I run those tests it might result into memory 
> corruption ?
>
> I don't think it is a good idea to ship Pharo with this memory corruption 
> tests in IslandVMTweaksTestCase. I suggest that if the tests may really 
> corrupt memory we remove them from Pharo, or if they cannot corrupt memory 
> then we fix the memory corruption comment.
>
> Yes, we should not ship code like that.
>
> Marcus
>
>

Re: [Pharo-project] BalloonCanvas>>drawPolygon

[Fernando Olivero]

Yes, we should fight against the jagged figures of our Morphs! Cairo
is a first step. Another option would be to work on a different Athens
backend for IOS, based on Quartz. The overall goal is to ditch Cairo
in favor of hardware accelerated backends.

Fernando

On Mon, Feb 25, 2013 at 4:15 PM, Hilaire Fernandes
 wrote:
> I turn DrGeo canvas to use Balloon to be at today standard regarding
> anti aliasing. Rendering polygon was the only issue I met with Balloon,
> even if its rendering is not exempt of unwished artifacts.
> No doubt Athens will be better but it adds the task to get Cairo on iOS
> and Android VM.
>
> Hilaire
>
>
>
> Le 24/02/2013 21:14, stephane ducasse a écrit :
>> this is not an issue that we were aware of. At least I did not.
>>
>> On Feb 24, 2013, at 8:06 PM, Hilaire Fernandes  
>> wrote:
>>
>>> Hello,
>>>
>>> When I use this method I get a beautiful red rectangle.
>>> And I can read http://bugs.squeak.org/view.php?id=7598
>>>
>>> Do someone confirm the issue?
>>>
>>> Thanks
>>>
>>> Hilaire
>>>
>>>
>>
>>
>>
>
>
>

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

[Fernando Olivero]

Hi, i had the same misconception once, but i recall Lukas pointed out
that the refactoring engine is built on the original refactoring's
from Fowler's book, and implemented in Smalltalk by Roberts and
Johnson [1].

So the semantics of the refactoring are preserved in the implementation.

If you just want a method rename, not a method refactoring rename,
maybe is best have an option for that in the menu [2].


Fernando

[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf
[2] or use a better widget for editing methods, than a simple code
editor within the pane of the browser, as in Gaucho..which i'm working
on.

On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano  wrote:
> and you are right, scoped browsing is a very powerful feature that can be 
> tricky to newcomers... but at least now with nautilus it is there, as first 
> option (in OB it was there, but more or less hidden in a submenu)...
> It is a small step, but is something... and well... we can improve in next 
> releases, one step at a time :)
>
> Esteban
>
> On Feb 20, 2013, at 10:52 AM, "p...@highoctane.be"  wrote:
>
>> Yes, thanks, I figured that out. A newcomer wouldn't... and renaming
>> is pretty common.
>>
>> What will happen is that people will remove the method and recreate a new 
>> one.
>> Version history will then go away.
>>
>> Or is the system smart enough to find out about these things?
>>
>> Phil
>>
>> 2013/2/20 Esteban Lorenzano :
>>> hi,
>>>
>>> yes, you are right.. but that is a "nice to have", not a bug... so it will 
>>> wait to 3.0 :)
>>> In the mean time, you can do a scoped rename: you select the packages you 
>>> want, then right click and "browse scoped", then you apply you rename, and 
>>> it will apply the refactor in the scoped selection, not all the image.
>>>
>>> cheers,
>>> Esteban
>>>
>>> On Feb 20, 2013, at 10:21 AM, "p...@highoctane.be"  
>>> wrote:
>>>
 Well, look at the screenshot then tell me that this is what I want.

 It is definitively *not* what I want. Especially unchecking that
 endless list of methods.

 Adding a "Uncheck all" "Check all" button to the Changes Browser list
 would help...

 Regards
 Phil

 2013/2/20 Camillo Bruni :
> there is 1 certain bug, that is that you cannot see the changes of the 
> refactoring:
>
> https://code.google.com/p/pharo/issues/detail?id=7547
>
> the rest I would consider a bug as well. But in the terms of refactoring 
> it might
> be "valid". It does preserve behavior by renaming also all implementors.
>
> How about this reasoning:
>
> Rename method
> => rename all senders (since you refactor)
> => you have to rename all implementors as well since you renamed all send 
> sites
>  otherwise you'll run for sure into a DNU
>
> I think I just convinced myself :D
>
> On 2013-02-20, at 09:26, "p...@highoctane.be"  wrote:
>> I was doing a Refactoring>rename of the initialize method in Nautilus
>> for the ClassMethodBrowser and then the changes browser proposed me to
>> change all classes with initialize. WTF?
>>
>> Phil
>>
>
>
 
>>>
>>>
>>
>
>

Re: [Pharo-project] Smalllint for Traits

[Fernando Olivero]

Hi, check out the following links.

http://www.pharo-project.org/license

http://pharo.gforge.inria.fr/licenseDocuments/PharoSoftwareDistributionAgreement.pdf

Saludos,
Fernando

On Tue, Feb 19, 2013 at 1:01 AM, aizcorbe
 wrote:
> No, i didn't sign any licence, what is this about?
>
>
>
> --
> View this message in context: 
> http://forum.world.st/Smalllint-for-Traits-tp4662559p4670573.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

Re: [Pharo-project] Smalllint for Traits

[Fernando Olivero]

Cool, thanks for investing time into this effort.

I guess the next step would be to work on the UI: improve Nautilus.

Fernando

On Mon, Feb 18, 2013 at 7:48 AM, Marcus Denker  wrote:
>
> On Feb 18, 2013, at 5:44 AM, aizcorbe  
> wrote:
>
>> I just uploaded an migration of the Smalllint for Traits using Nautilus and
>> Pharo 2.0.  I added the information here:
>> http://code.google.com/p/pharo/issues/detail?id=7223.
>>
> Very good! We should have a look at this and integrate it early in 3.0
>
> Marcus
>
>

Re: [Pharo-project] TxTextMorph based on new text model

[Fernando Olivero]

Hi, this is really interesting! To have a simpler text model and UI.


I recall Safara, in squeaksource. Lukas and a student worked on a nice text
model. Worth checking it out.

Fernando


On Fri, Feb 15, 2013 at 12:29 AM, Sean P. DeNigris wrote:

> Thanks again for tackling this! I'm definitely available to collaborate :)
>
>
> Denis Kudriashov wrote
> > Do you think that presenting any letter with real object (not just
> > character) is sufficient for modern computers? I think not. Of course
> such
> > model significantly simplified all logic around text layout stuff. But I
> > think it is too expensive.
>
> I don't know how efficient it would be, but how much text do we really
> layout at once? If it makes the code simpler and more beautiful, then it
> would be my starting point. Doing otherwise is premature optimization.
>
>
> Denis Kudriashov wrote
> > Another thing which I always not agree is introduction scripting
> languages
> > inside smalltalk... [but] I like what they do inside rules. It is
> > really simple and understandable code.
>
> Yes, I think a special scripting language would be way outside the bounds
> of
> Pharo, but the rules idea simplicity of that style could be great for us :)
>
> Cheers,
> Sean
>
>
>
> --
> View this message in context:
> http://forum.world.st/TxTextMorph-based-on-new-text-model-tp4663219p4669991.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
>

Re: [Pharo-project] Migrated HashTable from ss to SmalltalkHub

[Fernando Olivero]

Interesting, nice thesis Camilo.
Why not replace Dictionary then? At least it should be integrated into
Collections, in the image.
Fernando



On Sun, Feb 10, 2013 at 4:38 PM, Camillo Bruni wrote:

>
> On 2013-02-10, at 16:34, stephane ducasse 
> wrote:
>
> >
> > On Feb 10, 2013, at 4:22 PM, Sven Van Caekenberghe  wrote:
> >
> >>
> >> On 10 Feb 2013, at 15:16, Stéphane Ducasse 
> wrote:
> >>
> >>> - migrated all the history
> >>> - defined configurationOf
> >>> - All tests are green under 1.4 and 2.0
> >>>
> >>> Stef
> >>
> >> Dear I ask: what is HastTable and how it is different from Dictionary ?
>
>
> I think it's a dictionary implementation based on buckets (as any other
> decent
> dictionary implementation does...)
>
> I've shown in my master thesis that a simple bucket-based dictionary can
> outperform
> our poor-mans single array collection dictionary in almost every
> operation. The only
> drawback is the slightly bigger size in memory.
>
> http://scg.unibe.ch/archive/masters/Brun11a.pdf
>

Re: [Pharo-project] Extent a Athens surface?

[Fernando Olivero]

Hola Vanessa,

i can help you if, but i don't  fully understand what do you want to
achieve by "extending" the surface.

Saludos,
Fernando


On Mon, Jan 28, 2013 at 10:17 PM, Vanessa Peña Araya
wrote:

> Hi,
>
> I wanted to ask if it's possible to extent an Athens surface. If it
> can't be done, because as far as I understand this can't be done in
> Cairo, is it possible to simulate it at least? Is it possible to stop
> #drawDuring: and build another surface, maybe?
>
> Thanks,
> Vanessa.
>
>

Re: [Pharo-project] Fwd: More progress...

[Fernando Olivero]

Hi Marcus, this are great news!

For the less-knowledgable in OPAL, were can we read more about it?

Fernando


On Mon, Jan 28, 2013 at 1:15 PM, Sven Van Caekenberghe  wrote:

> Yes !
>
> Looking forward to it…
>
> On 28 Jan 2013, at 13:09, Marcus Denker  wrote:
>
> > … maybe others are interested.
> >
> > Begin forwarded message:
> >
> >> From: Marcus Denker 
> >> Subject: More progress...
> >> Date: January 28, 2013 1:07:19 PM GMT+01:00
> >> To: "pharo-compi...@lists.gforge.inria.fr" <
> pharo-compi...@lists.gforge.inria.fr>
> >>
> >> Hi,
> >>
> >> Lots of progress…
> >>
> >> -> BC to Text mapping (highlighting in the debugger)
> >>   Instead of building the mapping in the code generator, we
> instead
> >> enhanced the AST and IR to have all the right information
> and needed
> >> mapping.
> >>
> >>   This means: we can query the AST for "which statement
> generated the byte code at offset 24?"
> >>   Or "which BlockNode is the one for this Context?".
> >>
> >>   The AST combined with the  Scope/Var annotations and the IR
> contains all information needed,
> >> and in cases where something is wrong it is easy to debug.
> >>
> >> -> Correct Temp Vars for Contexts (via the Scope/Var knowledge)
> >>  For accessing temps in blocks in the debugger.
> >>  Here we delegate queries to the annotated AST, this means the
> Debugger uses
> >>the same data structures as the compiler when it wants to
> know about e.g. local temps.
> >>
> >>  One of the nice effects is that the needed machinery is much
> simpler:
> >>
> >>  DebuggerMethodMap linesOfCode 164
> >>  DebuggerMethodMapOpal linesOfCode 62
> >>
> >>  it is actually so simple that in a second step, there is no need
> for DebuggerMethodMapOpal at all,
> >>the code can be moved directly to better places (e.g.
> MethodContext). Caching is handled by ASTCache.
> >>
> >> -> Error Handling is working. All the error handling (Parsing and
> Semantic) are handled the same as
> >> the old compiler.
> >>
> >> TODO
> >>  => Pass over integration. Clean up the Compiler/Parser facades.
> >>(We will first have the whole thing to be compatible to the
> old from the Compiler/Parser POV,
> >>   here more cleanups are following after we have the stuff
> in the image)
> >>
> >>  => Pass over the decompiler. BC->IR is working, IR->AST needs to
> be checked.
> >>
> >>  => Fix all showstoppers here:
> http://code.google.com/p/pharo-newcompiler/issues/list
> >>
> >>
> >>  Marcus and Clement
> >>
> >
>
>
>

Re: [Pharo-project] Athens replacement for ImageReadWriter?

[Fernando Olivero]

What you can with Athens and the  Cairo backend  is:

1) create a surface in memory
2) draw to the surface
3) export that surface to a png
4) import that png into a form


The main point is step 3, cairo can export any surface to a png. Then
within Pharo, any form can be created from a png.

Also, if you interested in drawing from Athens into a form directly, look
at the AthensDemoExamples, and Igor's magic trick of matching the bits of
the surface (step 1), directly to the bits of an "external" form. to avoid
steps 3 and 4.  He used the surface plugin for that.

Hope i answered all your questions, though not sure because i've never used
ImageReadWriter.

Fernando




On Wed, Jan 23, 2013 at 6:38 AM, Denis Kudriashov wrote:

> I have same question :))
>
> 2013/1/23 Esteban Lorenzano  esteba...@gmail.com>>
> Hi,
>
> So, ImageReadWriter currently reads image files and retrieve Form objects,
> who can be displayed in world...
> anybody knows (cough, cough, Igor) what would be the Athens replacement
> for that?
>
> thanks,
> Esteban
>
>
>
>

Re: [Pharo-project] RateLimitingAnnouncer

[Fernando Olivero]

Hi, instead of subclassing Announcement, i would add the limiting logic to
the one receiving the announcements. To keep everything but the view
agnostic of this "optimization" detail. Because all you need is to prevent
the UI from rendering in intervals less then 100ms. The announcement
doesn't care wether the UI should redraw or not.


Fernando


On Sun, Jan 20, 2013 at 11:16 AM, Stéphane Ducasse <
stephane.duca...@inria.fr> wrote:

>
> On Jan 20, 2013, at 10:27 AM, Ben Coman wrote:
>
> >
> > I am considering a use case where a complex UI rendering loop is linked
> to an Announcement, which is being fired rapidly (eg < 1ms), and overall
> system performance suffers. However the UI rendering loop really only needs
> to execute every 100ms since that is sufficient for a user to perceive an
> immediate response to their action.  So I have rolled-my-own way to achieve
> this for which I was looking for some feedback...
> >
> > 1. Is there any existing feature in Pharo I have missed that can limit
> the firing rate of an announcement ?
>
> not that I know :)
>
> > 2. Would this be useful to others as a feature to ship with Pharo ? (so
> I don't have to roll-my-own, and it gets more experienced eyes to ensure
> its right :) )
>
> > 3. General comments on my approach, improvements, alternatives.
> >
> > By way of a use case using Workspace, execute...
> > -
> > | announcer mainCount  uiCount |
> > announcer := Announcer new. "RateLimitingAnnouncer new."
> > mainCount := uiCount := 0.
> > Transcript crShow: 'ui' ; tab; show: 'main' .
> > announcer subscribe: AnnouncementMockA do:
> > [ uiCount := uiCount + 1.
> >   "Imagine a longer duration UI rendering loop here"
> >   Transcript crShow: uiCount asString , '   ' , mainCount asString.
> > ].
> > [1 timesRepeat:
> >   [mainCount := mainCount + 1.
> >   "(Delay forMilliseconds: 1 ) wait."
> >announcer announce: AnnouncementMockA new.   ]
> > ] timeToRun .
> > -
> > With 'Announcer' this takes 10 seconds to execute with the last lines
> being...
> >    
> > 1   1
> >
> > Replacing 'Announcer' with my own 'RateLimitingAnnouncer' listed below,
> this takes 20 milliseconds with the last lines being...
> > uimain
> > 1   1
> > 2   1
> >
> > Uncommenting the "Delay" takes 30 seconds for Announcer - and 15 seconds
> for RateLimitingAnnouncer with last lines of...
> > 289   9935
> > 290   1
> >
> >
> > Here is my code wrapping #announce: and #initialize...
> > -
> > Announcer subclass: #RateLimitingAnnouncer
> >   instanceVariableNames: 'maxRateMilliSeconds queuedCounts'
> >   classVariableNames: ''
> >   poolDictionaries: ''
> >   category: 'LEKtrek-Core'
> > -
> > RateLimitingAnnouncer >>initialize
> >   super initialize .
> >   maxRateMilliSeconds := 100.
> >   queuedCounts := Dictionary new.
> > -
> > RateLimitingAnnouncer >>announce: anAnnouncement
> >   | announcementClass |
> >
> >   "Track how many announcements fired since reset at end of forked Delay"
> >   announcementClass := anAnnouncement class.
> >   queuedCounts at: announcementClass
> >   ifPresent: [ :count | queuedCounts at: announcementClass put:
> count + 1 ]
> >   ifAbsent: [ queuedCounts at: announcementClass put: 1 ].
> >
> >   "At first announcement since Delay'ed reset, forward this one and set
> up Delay to condense subsequent ones. "   ( (queuedCounts at:
> announcementClass) = 1 ) ifTrue:
> >   [  ["fire one announcement only for any announcement
> arriving within delay period."
> >   (Delay forMilliseconds: maxRateMilliSeconds) wait.
>  [ (queuedCounts at: announcementClass) > 1 ] whileTrue:[
>  "At least one announcement arrived before end of Delay. Forward one
> announcement only and repeat"  queuedCounts at:
> announcementClass put: 1.
> >   super announce: anAnnouncement.
> >   (Delay forMilliseconds: maxRateMilliSeconds) wait.
>  ].
> >   queuedCounts at: announcementClass put: 0.
> >   ] fork.  ^ super announce: anAnnouncement.  ].
> > -
> >
> > cheers -ben
> >
> >
>
>
>

Re: [Pharo-project] Smalllint for Traits

[Fernando Olivero]

Cool work! It would be nice to have in the latest Pharo 2.0, so it can be
integrated.
Think about integrating it into SmallLint, if not, your nice work maybe
will get lost.
Saludos,
Fernando


On Wed, Jan 9, 2013 at 2:04 AM, aizcorbe
wrote:

> Hi all, as part of a thesis I have been working on, I extended Smalllint to
> let it check Traits and Traits specific errors.
>
> The enviroment objects and the refactoring scope browsers now handles and
> list classes and traits (before they just handled classes).  The new
> refactoring scope selection is available at  "refactoring scope>selection
> all behaviors" menu option.
>
> The smalllint framework have been extended and is available at
> "refactor>code critics extended".
> These are some of the changes:
> smalllint rules can now check traits and traits methods.
> a new rule presentation schema is available, which lets to spot the place
> where the error is actually located and also add extra information to the
> rule result (but is more difficult to define the rules in this way).
>
> For extra information about the changes and how can they be used you can
> refer to:
>
> http://dc.uba.ar/inv/tesis/licenciatura/2012/aizcorbe.pdf (refer to
> chapter
> 4 if you want to bypass all the conceptual background )
>
> there was also added some rules to check Traits specific errors.
>
> The Smalllint for Traits extension is available for pharo 1.3 and is
> located
> in:
>
> http://www.squeaksource.com/TesisTraitLint
>
> the packages are organized as follows:
>
> OBLintTraitExtension.1.3 (the smalltalk environment extension to add Traits
> handling capabilities).
> TraitLint.1.3 (the Smalllint extension itself and the
> Traits
> rules implementation).
> TraitLintTest.1.3   (the unit tests for the Smalllint extension and
> the rules implementation, it is not mandatory).
>
> I hope you find this useful.
> cheers
>
>
>
> --
> View this message in context:
> http://forum.world.st/Smalllint-for-Traits-tp4662559.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
>

Re: [Pharo-project] About morph layout

[Fernando Olivero]

Hi, a couple of years ago, i tried to port Small Morphic from CUIS to
Pharo1.2.

After a couple of weeks i gave up, because there are to many relations
between the UI framework and the underlying system, which made it not just
a matter of UI porting, but a complete system diff.

Morphic relies on some kernel graphics which slightly differ in both
systems (Form, Canvas, etc..), and on the base object model infrastructure,
and some IDE related objects such as SystemNavigation , UIManager, etc..

I prefer the approach taken by Stef and other community members, clean the
current system one step at a time. Maybe, there will be some overlapping
with Juan's great work on CUIS, but on the bright side you wont get burned
trying to port, manage, and plug a new Morphic into Pharo.

Fernando

pd: It was so hard, i decided to start a new UI framework from the ground
up.




On Wed, Jan 2, 2013 at 7:52 PM, Chris Muller  wrote:

> Craig's NAIAD stands for "Name And Identity Are Distinct".  Just
> thinking aloud -- because Morphic is so entrenched..  Could NAIAD or
> Colin's Environments allow Juan's Morphic (or, Morphic3) to co-exist
> with original Morphic, so that it would allow working on the port
> without depending on it for the tools?  Once the port was complete, a
> sane migration could more easily occur..
>
>
> On Wed, Jan 2, 2013 at 7:00 AM, Igor Stasenko  wrote:
> > On 2 January 2013 12:55, H. Hirzel  wrote:
> >> Hello again Igor
> >> and Happy and Successful New "Pharo" Year 2013
> >>
> >
> > Thanks Hannes :)
> > Wish best to you in New Year too :)
> >
> >
> >> --Hannes
> >>
> >> my notes are inserted below.
> >>
> >>
> >> On 12/24/12, Igor Stasenko  wrote:
> >>> On 24 December 2012 09:43, H. Hirzel  wrote:
>  Hello Igor
> 
>  Thank you for this interesting mail. An issue over 11 years old, see
>  below.
> 
>  On 12/24/12, Igor Stasenko  wrote:
> > Hi,
> >
> > just wanna share some ideas about how we can cleanup morph a bit.
> 
>  A bit?
>  It will be a lot of effort.
> 
> >>> We can do it in small steps.
> >>>
>  Squeak 4.4-12234 (current)
> 
> Morph selectors size1183
> 
> 
>  Pharo 2.0 (Beta)
> 
> Morph selectors size  865
> 
> 
>  Cuis 4.1 (18th Dec 2012)
> 
>  Morph selectors size 343
> 
> 
>  This was an issue in 2001
> 
>  http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt
> 
>  see
> 
> >>> I am not first day here, of course i am aware of this :)
> >>
> >> Did you start working with Squeak already in 2001?
> >>
> > no. But i know this is a long standing issue :)
> >
> > Layout.. bizarre.
> 
>  Yes, see humorous contribution from June 2001
>  http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt
> 
>  search for
> 
>   the Morph class has 924 methods
> 
>  in that mails
> 
>  There was an effort
>  Morphic Cleanup Project
> 
>  http://wiki.squeak.org/squeak/3005
> 
>  lead by
> 
>  Diego Gomez Deck
> 
>  It produced some results. But they did not reach far enough.
> 
> >>> yes yes.. i know.
> >>>
>  However Juan Vuletic was successful in coming up with a simpler
> Morphic in
>  Cuis.
> 
> http://www.jvuletich.org/Cuis/Index.html
> 
> >>> search this mailing list for Small Morphic.
> >>> It was an attempt to use Juan's work, which didn't fly.
> >>
> >> Of course I am aware of SmallMorphic. If a first attempt at
> >> integrating SimpleMorphic into Pharo was not successful it does not
> >> necessarily mean that a second one has to be a failure again.
> >>
> >> Time spent on an analysis why it didn't fly is surely not a waste.
> >>
> >> For example another approach could be instead of copying code from
> >> Cuis and implanting it into Pharo "blob style"  you could follow Juan
> >> Vuletich's refactoring steps incrementally and copy smaller chunks of
> >> code. Cuis had many releases until it reached version 4.1.
> >>
> >> In terms of factoring out classes from the class Morph you seem to
> >> want to do that anyway.
> >>
> >> See for example
> >>
> >> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html
> >> New in Cuis 2.7 (released September 3, 2010)
> >>
> >> *Morphic. New LayoutSpec mechanism. Simpler and nicer.
> >> *Morphic Simplification: Layout, Extensions, etc
> >>
> >
> > Well, one thing is that Juan doing quite radical changes to code.
> > He is not concerned about backwards compatibility (but unlike from
> Pharo, nobody
> > raising it as an issue over and over again ;) ).
> > Yes, i checked new Cuis code.
> > I see a lot of simplifications. But also i see reduced functionality.
> > For instance, i did not found things like 'fill style',  and themes.
> > Also, i see some protocols is renamed, in preparation for something
> > bigger (morphic 3 i guess ;)
> >
> > So, i agree we sh

Re: [Pharo-project] Is there a simple example of how to create a GUI form in Pharo or Squeak?

[Fernando Olivero]

Hi, two good sources of information on GUI building are

http://www.pharocasts.com/2011/02/pharo-gui-with-polymorph.html?utm_source=BP_recent

http://book.pharo-project.org/book/LanguageAndLibraries/GUI/?_s=yllsSvKBo5cvoj5u&_k=SfVzYouSPsm74NVf&_n&6

They're not that hard to find (if you are aware of the Collab book and the
pharocasts).

You might want to check out Glamour also,
http://www.themoosebook.org/book/internals/glamour


Fernando


On Mon, Dec 24, 2012 at 11:22 AM, Frank Church  wrote:

> Is there a simple example of how to create a GUI form in Pharo or Squeak?
>
> I want to accomplish a simple task with a form:
>
> 1. Create a form with a button and edit control and 2 text areas.
>
> 2. Enter a value into the edit control.
>
> 3. Run a database query using the value in the edit control as a parameter
> and return the results in text area 1
>
> 4. Run a shell script using the value in the edit control as a parameter
> and return the results in text area 2
>
> I have OpenDBX running successfully and I don't think using OSProcess and
> CommandShell will be that difficult.
>
> Creating the form is the part I don't know how to accomplish.
>
> I have done some searching and there seems to be a surprising dearth of
> info on how to create a simple GUI from scratch using Pharo or Squeak.
>
> --
> Frank Church
>
> ===
> http://devblog.brahmancreations.com
>

Re: [Pharo-project] A contorted way of making things work :)

[Fernando Olivero]

Well, the assignment within the and: block says it all…

Fernando


On Sat, Dec 22, 2012 at 2:57 AM, Igor Stasenko  wrote:

> StringMorph>>boundsForBalloon
> "Some morphs have bounds that are way too big.  This is a contorted
> way of making things work okay in PluggableListMorphs, whose list
> elements historically have huge widths"
>
> | ownerOwner |
> ^ ((owner notNil and: [(ownerOwner := owner owner) notNil]) and:
> [ownerOwner isKindOf: PluggableListMorph])
> ifTrue:
> [self boundsInWorld intersect: ownerOwner
> boundsInWorld]
> ifFalse:
> [super boundsForBalloon]
>
> --
> Best regards,
> Igor Stasenko.
>
>

[Pharo-project] About (backwards) Compatibility

[Fernando Olivero]

Hi, i wanted to share an "old" quote which i find relevant to
our community. Just replace FORTRAN's with loads of stuff we had in the
bloated images in the past,  most of them useful to get were we are right
now.

"FORTRAN's tragic fate has been its wide acceptance, mentally chaining
thousands and thousands of programmers to our past mistakes. I pray daily
that more of my fellow-programmers may find the means of freeing themselves
from the curse of compatibility."

Dijkstra, The Humble Programmer, 1972

Re: [Pharo-project] How to manipulate HandMorph's position?

[Fernando Olivero]

HandMorph is only drawn when its carrying another morph. What you see in
the screen is the "hardware cursor", maintained by the vm.
This separation was done for efficiency reasons, when drawing Morphic.

This is why you evaluate stuff like Cursor wait showWhile:[], to alter the
appearance of the "hand/cursor", instead of changing the HandMorph directly.

So what you are doing by sending the message above is simply positioning a
hidden morph, the hand, at a 10@10.

Maybe, try to see if you can position programmatically the Cursor instead.

Saludos,
Fernando



On Mon, Dec 10, 2012 at 9:10 PM, Carla F. Griggio
wrote:

> Hi everybody!
>
> I'm trying to implement some Kinematic Templates<
> http://hci.uwaterloo.ca/sites/default/files/uist_madness_kin_templates.mov>
> in Pharo for a course assignment. For that, I'm trying to modify the
> position of the HandCursor, but trying to evaluate naive messages like:
>
> ActiveHand position: 10@10
>
> leaves me nowhere.
>
> Is there some black magic I need to know about the HandMorph in order to
> manipulate it's position they way I want?
>
> Thanks!
>
> Carla.
>

Re: [Pharo-project] Versioning external packages

[Fernando Olivero]

Hi Roberto, in the first case you have to add the methods in a category
named: '*MyPackage', then  Monticello versions it as an method "extension",
a method of you package which is in a class that doesn't belong to your
package.

OrderedCollection>>myMethodExtension
   " I'm in a method category starting with an asterisk *"
   self doSomething.

In the second case, you should put the class in your package, so it would
be versioned (and be part of), your package, but still accessible
throughout the image. But, if you think your new Roassal Layout is cool
enough, then you should tell the package maintainers to add it to Roassal.

Saludos,
Fernando





On Tue, Nov 27, 2012 at 12:12 PM, roberto.mine...@usi.ch <
roberto.mine...@usi.ch> wrote:

> Hi all,
>
> I'm using Monticello to version my source code.
>
> Suppose this use case: I need to add a message to the OrderedCollection
> class and I want my message to be versioned within my repository (i.e.,
> when an user downloads my package she also get the new message in the
> OrderedCollection class.
>
> And another one, suppose I create a new Layout for Roassal that suits my
> needs. I will create a class in the category 'Roassal-Layout' which is not
> versioned in my repository. Is there a way to version it?
>
> Cheers,
> Roberto
>

Re: [Pharo-project] MongoTalk update

[Fernando Olivero]

Hi, this seems to answer your question.

http://articles.tulipemoutarde.be/embedded-document-with-voyage-in-mongodb

Fernando


On Sun, Nov 25, 2012 at 2:09 AM, Igor Stasenko  wrote:

> On 24 November 2012 14:06, Nicolas Petton 
> wrote:
> >
> > Thanks Norbert!
> >
> > It's cool to know that you like it :) Together with Esteban's work on
> > Voyage, it allows us to do extremely cool stuff with Mongo and Pharo.
> >
> > What I like with Voyage-Mongo + MongoQueries is that objects are
> > persisted without any effort, it just works, and we can query Mongo
> > collections like we would do with Smalltalk collections.
> >
> are you talking about serializing objects (or subgraphs) directly, and
> storing them in mongo db ?
>
> > Nico
> >
> > Norbert Hartl  writes:
> >
> >> Hey Nico,
> >>
> >> I looked into your new stuff and I like it. Especially the MongoQueries
> stuff is very simple and clean approach to do a small DSL. That boosts the
> usability of MongoTalk extremely. Bravo!
> >>
> >> Norbert
> >>
> >> Am 19.11.2012 um 15:37 schrieb Nicolas Petton  >:
> >>
> >>>
> >>> Hi guys,
> >>>
> >>> Lately I worked a bit on the Pharo Mongo driver for SmalltalkHub. I
> made
> >>> several changes (in the new version 1.4):
> >>>
> >>> The query API changed:
> >>>
> >>> - MongoCollection>>query: now takes a 1 arg block, improving the API
> >>> quite a bit.
> >>>
> >>> Queries like:
> >>>
> >>> aCollection query: (aCollection query
> >>>query: { 'foo' -> 'bar'} asDictionary;
> >>>yourself)
> >>>
> >>> Is now written:
> >>>
> >>> aCollection query: [ :query |
> >>>query where: { 'foo' -> 'bar'} ]
> >>>
> >>> Sending #asDictionary has also been made optional, the query builder
> >>> will send #asMongoQuery to the query collection.
> >>>
> >>>
> >>> The MongoQueries package:
> >>>
> >>> Version 1.4 comes with a new package MongoQueries, a small DSL allowing
> >>> us to use traditional blocks instead of dictionaries to perform
> >>> queries. This is optional and backward compatible.
> >>>
> >>> Queries like:
> >>>
> >>> aCollection select: { '$or' -> { 'name' -> 'foo'. 'age' -> { '$gt' ->
> 23 }
> >>> asDictionary } asDictionary } asDictionary
> >>>
> >>> can be expressed:
> >>>
> >>> aCollection select: [ :each | (each name = 'foo') | (each age > 23) ]
> >>>
> >>> The MongoQueries package should support the entire mongo query language
> >>> (including nested queries), and comes with unit tests.
> >>>
> >>> Nico
> >>>
> >>
> >>
> >
> > --
> > Nicolas Petton
> > http://nicolas-petton.fr
> >
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>

Re: [Pharo-project] Athens OpenGL backend - what does it mean?

[Fernando Olivero]

yes! But not only it would enable having multiple windows, because now we
"downgrade" all the events to the minimum common denominator, and pass a
"raw event" captured from each OS, from the vm to the image.

would be nice to do some surgery on the vm, and cut the windowing
management and raw event handling away. It belongs in the image, if it can
be implemented using NB to the OS UI frameworks, or in a separate app.

We just need a surgeon with the time and ability to do so….i've tried in
the past and the related VM code was really hard to understand.

Fernando
pd: There were some discussion around this idea last year in the mailing
list.



On Sun, Nov 25, 2012 at 9:40 AM, Stéphane Ducasse  wrote:

>
> On Nov 24, 2012, at 5:19 PM, Sebastian Nozzi wrote:
>
> >> sure thing i want as many as we want.
> >
> > Excellent!
> >
> >> we need to change VM, to let image be in better control of host system
> windows.
> >> once we will have that, having multiple windows & effects will not
> >> pose any problems anymore. :)
> >
> > Now when you say "host system windowS" you mean... that the plan is to
> > have *many* host windows, not just one as is the case? :-O
>
> we would love that.
> This is not because there is not something right now that this is
> something we do not want.
> We just try to make progress and not open too many projects. Finishing is
> important to pass to the
> next level.
>
>
> >
> > I was just referring to the Morphic class SystemWindow...
> >
> > Cheers,
> >
> > Sebastian
> >
>
>
>

Re: [Pharo-project] New Athens+Chipmunk example [WAS: Re: Athens, Nativeboost and Igor's gray hair]

[Fernando Olivero]

I've just browsed through the code.

Nice work on modeling Chipmunk in the image via NB.

Could you separate this work from Storm? I think it deserves a package on
its own.

Fernando


On Sat, Nov 24, 2012 at 11:55 AM, fernando.oliv...@usi.ch <
fernando.oliv...@usi.ch> wrote:

> Nice example Esteban, now you need to add some explosions to the game!
>
> Curious on the usage of Chipmunk, do you replicate the walls, balls and
> gravity in smalltalk? Or use Athens just as "view".
>
> Fernando
>
>
> On Sat, Nov 24, 2012 at 11:50 AM, Esteban Lorenzano  > wrote:
> Hi,
>
> thanks.. my "video recording skills" still need a lot of improvement, but
> I'm having fun so far :)
>
> I have an i7 2.8Ghz
>
> Esteban
>
> On Nov 24, 2012, at 11:46 AM, dimitris chloupis  >> wrote:
>
>
> amazing stuff and it seems to run very fast taking also into account that
> you video record this. Thanks for sharing.
>
> What kind of processor you have ?
> 
> From: EstebanLM [via Smalltalk]   ml-node+s1294792n4656561...@n4.nabble.com ml-node%2bs1294792n4656561...@n4.nabble.com>>>
> To: kilon mailto:theki...@yahoo.co.uk> theki...@yahoo.co.uk>>
> Sent: Saturday, 24 November 2012, 12:41
> Subject: New Athens+Chipmunk example [WAS: Re: Athens, Nativeboost and
> Igor's gray hair]
>
> you ask it, you have it :)
>
> This is a new example of Athens+Chipmunk colliding 500 objects (1k works,
> but still needs some adjusts :)
>
> http://youtu.be/GkS6rHVUJko
>
> Esteban
>
> On Nov 24, 2012, at 10:48 AM, Stéphane Ducasse <[hidden
> email]> wrote:
>
> where are they these cool examples.
>
> Stef
>
>
> On Nov 23, 2012, at 7:16 PM, Esteban Lorenzano wrote:
>
> and you have to see my 1k small spheres falling into a pot :P
> (my objective is to get 2k and still be performant, I don't know if I will
> succeed, but is fun to try)
>
> and JB's joint example, btw :)
>
> Esteban
>
>
> On Nov 23, 2012, at 7:10 PM, Stéphane Ducasse <[hidden
> email]> wrote:
>
> You are welcome.
>
> Stef
>
> that what happens when i get tons of emails, i missed yours. But thanks to
> world of smalltalk i found it. Thanks for sharing that great stuff I am
> actually considering giving a helping hand to Athens , I really like it.
>
>
>
> --
> View this message in context:
> http://forum.world.st/Athens-Nativeboost-and-Igor-s-gray-hair-tp4656395p4656463.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com<
> http://nabble.com/>.
>
>
>
>
>
>
>
>
>
>
> 
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://forum.world.st/Athens-Nativeboost-and-Igor-s-gray-hair-tp4656395p4656561.html
> To unsubscribe from Athens, Nativeboost and Igor's gray hair, click here<
> http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4656395&code=dGhla2lsb25AeWFob28uY28udWt8NDY1NjM5NXwtMTEzNTM4MTMyMg==
> >.
> NAML<
> http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
>
>
>
>
>

Re: [Pharo-project] New Athens+Chipmunk example [WAS: Re: Athens, Nativeboost and Igor's gray hair]

[Fernando Olivero]

Nice example Esteban, now you need to add some explosions to the game!

Curious on the usage of Chipmunk, do you replicate the walls, balls and
gravity in smalltalk? Or use Athens just as "view".

Fernando


On Sat, Nov 24, 2012 at 11:50 AM, Esteban Lorenzano wrote:

> Hi,
>
> thanks.. my "video recording skills" still need a lot of improvement, but
> I'm having fun so far :)
>
> I have an i7 2.8Ghz
>
> Esteban
>
> On Nov 24, 2012, at 11:46 AM, dimitris chloupis  > wrote:
>
>
> amazing stuff and it seems to run very fast taking also into account that
> you video record this. Thanks for sharing.
>
> What kind of processor you have ?
> 
> From: EstebanLM [via Smalltalk]  >
> To: kilon mailto:theki...@yahoo.co.uk>>
> Sent: Saturday, 24 November 2012, 12:41
> Subject: New Athens+Chipmunk example [WAS: Re: Athens, Nativeboost and
> Igor's gray hair]
>
> you ask it, you have it :)
>
> This is a new example of Athens+Chipmunk colliding 500 objects (1k works,
> but still needs some adjusts :)
>
> http://youtu.be/GkS6rHVUJko
>
> Esteban
>
> On Nov 24, 2012, at 10:48 AM, Stéphane Ducasse <[hidden
> email]> wrote:
>
> where are they these cool examples.
>
> Stef
>
>
> On Nov 23, 2012, at 7:16 PM, Esteban Lorenzano wrote:
>
> and you have to see my 1k small spheres falling into a pot :P
> (my objective is to get 2k and still be performant, I don't know if I will
> succeed, but is fun to try)
>
> and JB's joint example, btw :)
>
> Esteban
>
>
> On Nov 23, 2012, at 7:10 PM, Stéphane Ducasse <[hidden
> email]> wrote:
>
> You are welcome.
>
> Stef
>
> that what happens when i get tons of emails, i missed yours. But thanks to
> world of smalltalk i found it. Thanks for sharing that great stuff I am
> actually considering giving a helping hand to Athens , I really like it.
>
>
>
> --
> View this message in context:
> http://forum.world.st/Athens-Nativeboost-and-Igor-s-gray-hair-tp4656395p4656463.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com<
> http://nabble.com/>.
>
>
>
>
>
>
>
>
>
>
> 
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://forum.world.st/Athens-Nativeboost-and-Igor-s-gray-hair-tp4656395p4656561.html
> To unsubscribe from Athens, Nativeboost and Igor's gray hair, click here<
> http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4656395&code=dGhla2lsb25AeWFob28uY28udWt8NDY1NjM5NXwtMTEzNTM4MTMyMg==
> >.
> NAML<
> http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
>
>
>
>

Re: [Pharo-project] Helping with Athens development

[Fernando Olivero]

For now, Athens uses the software renderer of Cairo to draw into a Cairo
Surface. We get it back to the Pharo, buy telling a Form to load the bits
of the Cairo surface.

Would be nice to have another renderer for Athens, besides Cairo, to use a
hardware accelerated renderer. OpenGL backend for Athens would be great.

NBOpenGL is already there. So it would a matter of having another
AthensCanvas, and AthensSurface that uses OpenGL to draw.

Yet, the current scheme is fast enough! So i don't know wether this is a
priority.

Fernando


On Fri, Nov 23, 2012 at 12:11 PM, dimitris chloupis wrote:

> So after diving in common lisp and take a look at various alternative I
> decided that Pharo is the best place for me to start for my Ephestos
> project. The first thing that got my attention is Athens , it seems to be
> very close to my own goal for Ephestos. So my question is how may I help
> Athens involve by contributing code to it ?
>
> Are there specific features I can work on ? The first part of my Ephestos
> project I call it Morpheas and its basically a GUI API based on morphic
> specialised on customised guis, meaning guis that do not look native .
> Athens seems a good library to base Morpheas on, so I am actually
> interested in expanding it.
>
> In the future I would also like to port Athens to opengl , but if cairo is
> fast enough for me, I may avoid it and instead focus more on porting
> Morphic to Athens.
>
> So my post here is to clarify the way I can contribute to Athens . I want
> my project Ephestos to be a contribution to the existing Pharo image and
> offer more GUI widgets, maybe a gui designer and some more graphic and
> audio tools. I think that Athens can be the base for my project so
> naturally I want to contribute.
>

Re: [Pharo-project] I don't agree with DummyXXX

[Fernando Olivero]

I totally agree.  Dummy does not tell me about the class.

Are there just 3 uses of Dummy in the core?

We should either use Null  or use a specific prefix always, so its form a
consisten pattern.

DummyUIManager -> NullUIManager

Fernando

On Wed, Nov 21, 2012 at 4:34 PM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:

> From what I understand, Dummy means something different. I have using that
> for class names. More accurate names can be found.
> I would rename:
>
> DummyUIManager -> HeadlessUIManager
> DummySystemProgressItem -> NullSystemProgressItem
> DummySoundSystem -> NullSoundSystem
>
> what do you think? do you have better names?
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>

Re: [Pharo-project] about sharing class binding and others

[Fernando Olivero]

I love Marcus idea, classes aren't globals any more, and to access them is
simply another  message send to a receiver: the environment. ( like the
lobby in Self ) .

Fernando


On Sat, Nov 17, 2012 at 8:56 AM, Stéphane Ducasse  wrote:

> > The alternative to the current scheme would be to not hard-code the
> class at all in the method at compile time.
> >
> > Instead of looking up the class and compiling the shared literal
> association, we could compile a message send
> > to the current environment.
> >
> > self class environment at: #NameOfClass
> >
> > And it should be noted that this could be evaluated at Jit-compile
> time... the same is true for ivar offsets. There
> > is no reason why these should be visible at the image level. The image
> could talk about names and let the runtime
> > translator infrastucture do the lookups needed for making a static
> version that is fast.
>
> Yes I would like to measure that too.
> My benchmarks were to measure the worse case where we have to manually
> update the methods each time the class is modified.
>
>
>

Re: [Pharo-project] [Pharo-users] [Pharo-consortium] Pharo Association

[Fernando Olivero]

Cool! It's great that now we have a way of supporting Pharo.

I thought it was a bug, but  realized that after signing up, you can login
but you wont appear in the members list before you actually pay.

Thanks,
Fernando


On Thu, Nov 15, 2012 at 6:09 PM, Tudor Girba  wrote:

> I did and it worked. So, it is safe for everyone else to do it, too :)
>
> Doru
>
>
> On 15 Nov 2012, at 17:58, Damien Cassou  wrote:
>
> > On Thu, Nov 15, 2012 at 4:29 PM, Tudor Girba 
> wrote:
> >> I see. I tried that just now, but it hangs after I press sign up.
> >
> > try again :-)
> >
> > --
> > Damien Cassou
> > http://damiencassou.seasidehosting.st
> >
> > "Success is the ability to go from one failure to another without
> > losing enthusiasm."
> > Winston Churchill
> >
>
> --
> www.tudorgirba.com
>
> "We cannot reach the flow of things unless we let go."
>
>
>
>
>

Re: [Pharo-project] [Pharo-users] CategorySaver

[Fernando Olivero]

Sebastian, thanks for sharing your code and thoughts.

Maybe what Mariano was implying is that you already have the data for the
backup in the changes, and having yet another mechanism for that adds
complexity to the system.

I think is a good idea, but too focused on the categories you choose up
front..and not on those actual changes you perform on the system.

Which is why the recovering from the changes file is better.

Dont worry, the image crashes every now and then to all of
us! fortunately since Pharo1.0, less and less every day...

Regarding the UI, you should check out Spec, by Benjamin and Stef. It's
easier to create morphs programmatically than with the raw Polymorph. And
also check out Glamour, the ones used in Moose.

Saludos,
Fernando






On Mon, Nov 12, 2012 at 8:55 PM, Damien Cassou wrote:

> On Mon, Nov 12, 2012 at 8:06 PM, Sebastian Nozzi 
> wrote:
> > P.S. 2 -- I was amazed at how easy it was to code the UI! UI
> > programming in Squeak/Pharo was always an area where I thought must be
> > incredible complicated, but thanks to UITheme's builder (Polymorph?)
> > it's a breeze. Good work!
>
> The new UI framework is Spec, I guess it's better than Polymorph but
> don't know how they compare.
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm."
> Winston Churchill
>
>

Re: [Pharo-project] NB Capabilities

[Fernando Olivero]

Hi, i wanted to give my opinion on this, since i've encountered some of the
problems you mention.

Sometimes to benefit from the simplicity of Smalltalk while coexisting with
other tools, we must cope with low level technology "glue code".

NB made it easy to do so, compared to Alien,FFI, writing plugins in C. When
i first started with Squeak and the Pharo1.0, it was a real pain
interfacing with external libraries, THANKS  Igor!

Still someones needs to do it, hence why a lot of people of
this community spent loads of time coding this "extra work" to be able to
do their "real work".

I wouldn't say that you need to be extremely bright to built a wrapper
library using NB, once you know what api you want to call, and the type of
arguments.

There's plenty of examples out there, and Igor always responds with tough
questions!

Give a try! maybe its easier than you think.

Fernando

On Fri, Nov 9, 2012 at 12:35 PM, drush66 wrote:

> Igor Stasenko wrote
> > AFAIK, COM is fairly simple. You need to do a lill parsing deciphering
> > IDL interface,
> > and frankly i don't remember all the details. But at the end, it is
> > just a bunch of C calls.
> > With NativeBoost you can do calls to C .. so it is doable.
> >
> > Again, Dolphin Smalltalk can use COM , so if it can be done there, i
> > don't see why it is impossible
> > to do the same in Pharo.
>
> well, Dolphin COM interface was written by two very bright chaps with
> intimate knowledge of their VM and system, good knowledge of windows and
> COM, over a rather long period.
>
> So I would say:
>
> - Doable: absolutely yes,
>
> - Feasible for someone who does not have solid experience in FFI and just
> needs to connect to this library so that he can do his real job: probably
> no.
>
>
>
>
>
> -
> http://www.cloud208.com/
> --
> View this message in context:
> http://forum.world.st/NB-Capabilities-tp4654570p4654615.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
>

Re: [Pharo-project] Increase memory

[Fernando Olivero]

Ciao Roberto, which is the current size of the image? (the .image file).


If you evaluate the following a couple of times (print it cmd-p), you will
cleanup most of the unreferenced objects in the image, it returns a number
so you can compare it to successive evaluations.

Smalltalk garbageCollect.

You can also follow the pointers to objects, to detect objects which you
suspect are just hanging around, and fail to be garbage collected, to clear
those references. Open an inspector an any object,and the menu has that
option. ( {Object. 1. #hello} inspect) .

You can also, start with a fresh image.


pd: if you search the mailing list, i remember Tudor writing about large
images and vm's.



On Thu, Nov 8, 2012 at 2:16 PM, roberto.mine...@usi.ch <
roberto.mine...@usi.ch> wrote:

> Hi,
>
> I was executing a piece of code that collects the revisions of a Git repo
> in Pharo but it seems Pharo requires more memory..
>
> How do I increase the available memory?
>
> Here is the log:
>
> SmalltalkImage>>signalLowSpace
> OutOfMemory>>defaultAction
> UndefinedObject>>handleSignal:
> OutOfMemory(Exception)>>pass
> PasteUpMorph>>becomeActiveDuring: in Block: [:ex | ...
> BlockClosure>>cull:
> MethodContext(ContextPart)>>handleSignal: in Block: [self
> exceptionHandlerBlock cull: exception]
> BlockClosure>>ensure:
> MethodContext(ContextPart)>>handleSignal:
> MethodContext(ContextPart)>>handleSignal:
> OutOfMemory(Exception)>>signal
> OutOfMemory class(Exception class)>>signal
> ByteArray class(Behavior)>>basicNew:
> ByteArray class(Behavior)>>new:
> ByteArray(SequenceableCollection)>>copyFrom:to:
> ReadStream(PositionableStream)>>contents
> GitPackedNonDelta(GitPackedObject)>>compressedData
> GitPackedNonDelta(GitPackedObject)>>computeCRC
> GitPackedNonDelta(GitPackedObject)>>loadFrom:
> GitPackedObject class>>fromPack:at:in:
> GitPackFile>>objectAtOffset:
> GitPackFile>>objectNamed:
> GitRepository>>packedObjectNamed:ifAbsent: in Block: [:pack | (pack
> objectNamed: aHexHash)...
> GitRepository>>packsDo: in Block: [:pack | aBlock value: pack]
> OrderedCollection>>do:
> GitRepository>>packsDo:
> GitRepository>>packedObjectNamed:ifAbsent:
> GitRepository>>objectNamed:ifAbsent: in Block: [self packedObjectNamed:
> aHash ifAbsent: aBlock]
> GitRepository>>looseObjectNamed:ifAbsent: in Block: [^ aBlock value]
> False>>ifTrue:ifFalse:
>
> Thanks,
> Roberto
>

Re: [Pharo-project] Smalltalk to Python and back

[Fernando Olivero]

Hi, you can get inspiration from http://clamato.net/, a similar approach
using petit parser to translate to javascript.

Fernando



On Thu, Nov 1, 2012 at 1:42 PM, dimitris chloupis wrote:

> Probably I have mentioned this several times but I am working on a project
> for visual programming targeting 3d app blender. I am using currently pharo
> though I am still interested in squeak too and I have decided that in order
> to communicate with blender python to use a socket bridge. My project is
> named "Ephestos". Now what was wondering is the following, how difficult it
> would be to parse smalltalk to python. Ephestos is of course smalltalk ,
> and blender uses python for its addon system. It would be great if
> extensions made in Ephestos could converted to python addons.
>
> I am already planning to map smalltalk methods to Blender python api call,
> but I was wondering how easy it would be to parse that code to python.
>
> So far I am aware of OMeta and Petit Parser libraries. What are your
> suggestions ?
>

Re: [Pharo-project] Global session object?

[Fernando Olivero]

Yes, session management is cross-cutting concern, so it makes sense to
have it in the system, and not just as a NB feature.

Object new, is a cool workaround for the unique ID!

Fernando

On Mon, Oct 8, 2012 at 8:33 AM, Marcus Denker  wrote:
> Hello,
>
> Yes, this sounds good.
>
> Marcus
>
> On Oct 8, 2012, at 5:11 AM, Igor Stasenko  wrote:
>
>> I wanna have this:
>>
>> SmalltalkImage>>snapshot: save andQuit: quit
>> ...
>> resuming ifTrue: [ session := self newSession ].
>> ...
>>
>> (where session is additional instance variable of SmalltalkImage).
>>
>> SmalltalkImage>>newSession
>> "Just answer unique object, which never can be identical to any
>> previous session object,
>> this is all what we need for detecting session change.
>> A session object don't needs to carry any state (we have plenty of
>> other objects in image which can do this for us). it just needs to be
>> unique"
>>
>>  ^ Object new.
>>
>> SmalltalkImage>>session
>> ^ session
>>
>> then, i can write in own code:
>>
>> Smalltalk session == mySession ifFalse: [  self initForNewSession.
>> mySession := Smalltalk session ]
>>
>> So, basically, this little addition allows you to detect whether
>> session changed or not between
>> two different calls to your code (given that you remembered the
>> previous session somewhere).
>> Currently we don't have such feature, and looking how some existing
>> code deals with session management,
>> i see how it can be simplified.
>> If you want to do something similar today, you will need to register
>> in startup list.. which IMO stinks ;)
>>
>> i don't like using startup lists, since you never know , what is the
>> right order of resource initialization,
>> and what inter-dependencies they may form, and changing dependencies
>> over time will require changing startup order, again and again. Not
>> fun.
>> This technique allows you to lazily re-initialize any of your
>> object(s) due to session change, once the control flow hits your code,
>> but not before.
>> (so you don't have to do all accounting at image startup time, you
>> doing it only when it required/requested, which means shorter image
>> startup time).
>>
>> The notion of session is highly important for external resource management.
>>
>> I using it in NativeBoost from very beginning, and wanna propose to
>> use it globally.
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>

Re: [Pharo-project] To try out FileSystem in 2.0 -- which download?

[Fernando Olivero]

i love they manner in which you summarized more then 10 years of
struggles, and introduce the high hopes that this future beholds...

thanks Marcus!

Fernando

On Thu, Oct 4, 2012 at 9:16 AM, Sven Van Caekenberghe  wrote:
> Thanks for the explanation and pointers, Marcus.
>
> Well written, well said, as usual ;-)
>
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
>
>
>
> On 04 Oct 2012, at 08:26, Marcus Denker  wrote:
>
>>
>> On Oct 4, 2012, at 8:02 AM, Marcus Denker  wrote:
>>>
>>> Now there are two philosophies
>>>
>>> 1) we load the new in addition. It even is compatible to many different 
>>> versions of the System, and everyone uses it
>>> in new code. But the sytem can not use it, as the developer of course wants 
>>> to load the latest version of this independendly
>>> develpopped library. Some people requested that for FileSystem, and we 
>>> renamed all classes so that they can continue
>>> to load the code themselves.
>>
>> This  actually is interesting, these two philosophies...
>>
>> 1) The Addition View
>>
>> Smalltalk is perfect and finished. Everything we do we do "on top". If we 
>> implement Morphic, we keep MVC. Things like
>> FileSystem code is there as an additonal library.
>> When doing research, the picture you have is not that of a System that you 
>> improve to make a new System that makes
>> the next research easier. No. You do something *on top*, and throw it away 
>> after.
>>
>> 2) The System View
>>
>> I think some people's brain kind of got a hickup when they looked at 
>> instances of Class and saw that they just use standard
>> libraries. MethodDictionay is a Dictionary... there is no special "I wrote 
>> everyhting again because I am clever!" code
>> even deep in the system. That is one of the things that makes Smalltalk 
>> powerful!
>>
>> The main reason is that it created a feedback loop: We improve something for 
>> an application. But then, instead of throwing
>> it away, we *apply* that improvement to the *whole* system. The system gets 
>> better (faster, smaller). And its expressiveness
>> is improved: the next developer can just *use* the improvement and put the 
>> time into something else.
>>
>> Especially in Research, this is quite important: You can't publish things 
>> that have already been done. Time is limited (just 3-4 years
>> to do a PhD...). So if the guy has to constantly start from scratch, this 
>> gets very hard after just some interations. Yet, when the System
>> itself improves... the picture here is that of a mountain: We can always 
>> climb up from the valley deep down, or we can build base camps.
>> Who will do better?
>>
>> I think we are starting to (slowly) see this with Pharo. E.g. the on-demand 
>> loading of the .sources. It uses Zinc and FileSystem, it's just a
>> couple of lines of code. Yes, you could have done it before. But would 
>> anyone do it? Of course not.  (just a very trivial example).
>>
>>   Marcus
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>>
>
>

Re: [Pharo-project] NB cant locate a module

[Fernando Olivero]

Ok, so the plot thickens!  thanks for the info Igor

I will follow your guideliness, and try to make Pango work
as you did with Cairo.

Fernando
pd: I also HATE all this non-smalltalk crap! So thanks for the blog and effort.

On Wed, Oct 3, 2012 at 2:06 PM, Igor Stasenko  wrote:
> On 3 October 2012 13:54, Fernando Olivero  wrote:
>> Hi Igor,
>>
>> following your example on using CairoLibraryLoader, i did the same for
>> the PangoCairo library part of Athens.
>>
>> But there's something i don't understand, why [1]  works and [2]
>> doesn't (it returns 0), if both are in  the plugins folder of the vm.
>>
>> 1.NativeBoost forCurrentPlatform loadModule:   'libcairo.2.dylib'
>> 2.NativeBoost forCurrentPlatform loadModule:  'libpango-1.0.0.dylib'
>>
>> Does it depend on something else besides being in that path?
>> #loadModule: by default looks
>> at the Plugins folder?
>>
>> I've also tried passing as an argument the full path.
>>
>> I've attached the dylib, compiled with Macports universal binaries option.
>>
>> I'm using MacOS.
>
> you want to put it into bundle, isnt?
>
> now, run
> otool -l libpango-1.0.0.dylib
>
> and you will see that this library has a lot of dependencies coming
> from /out/local/lib...
> and that's why i won't load on any other mac, than yours, because of
> missing dependencies.
>
> Don't expect these libs to be installed on other Mac machine.
> So, to bundle things properly you need to also copy these libraries
> into bundle (and also fix the references)..
>
> I mention about it here:
> https://computeradventures.wordpress.com/2012/06/10/bundling-vm-with-thirdparty-libraries/
>
> "The last thing about bundling (and it is Mac-specific) is to change
> the references in produced .dylib files to correct ones. I tried to
> use BundleUtils provided by cmake.. but it is prone to be buggy, so i
> had to write own. All it does is replacing an absolute paths in all
> .dylib-s (including external plugin libs) to path relative to .app
> bundle."
>
> without this, you won't be able to make a proper bundle.
>
> See, how i doing it in:
>
> MacOSConfig >> postBuildActions:
>
>>
>> Thanks,
>> Fernando
>
>
>
> --
> Best regards,
> Igor Stasenko.

Re: [Pharo-project] Fuel and Tanker in older Pharo images [WAS] Re: How to try Shapes and Gaucho?

[Fernando Olivero]

Cool!  Thanks Mariano for the summary, and all the others for this
much needed features! Looking forward to adopt such a process, to have
a minimal Pharo image, customized to my needs.

Fernando

On Sat, Sep 29, 2012 at 2:20 PM, Mariano Martinez Peck
 wrote:
>
>
> On Sat, Sep 29, 2012 at 12:59 PM, Denis Kudriashov 
> mailto:dionisi...@gmail.com>> wrote:
> 2012/9/29 Mariano Martinez Peck 
> mailto:marianop...@gmail.com>>
>
>
> On Fri, Sep 28, 2012 at 11:31 PM, Denis Kudriashov 
> mailto:dionisi...@gmail.com>> wrote:
> Hello
>
> ss3 repo for Shapes and Gaucho closed for reading or maybe empty.
> So is it possible to get it somewhere? maybe there is prepared image?
>
> Actually I gather migrate our applications to last Pharo and use latest 
> achievemens like fuel and tanker.
>
> Hi. I don't want to go offtopic in the original thread so I opened this one.
> Of course it is usually a good idea to migrate to latest stable Pharo release 
> so that you don't stay with a very old image. Anyway, what I wanted to say is 
> that Fuel DOES WORK in previous images. In fact, it works from Pharo 1.1 to 
> 2.0.  And Tanker right now works in 2.0 only by just because by default we 
> use the new ClassBuilder. But this can be easily changed for those who want 
> to use it in older versions. Anyway, Tanker is still a little bit green ;)
> For more details read my answer to this comment: 
> http://marianopeck.wordpress.com/2012/09/28/new-tanker-current-status/#comment-905
>
> Hello and thank's for response.
>
> Actually I want use Tanker to deploy my applications with "bootstrap way" 
> where only kernel minimal image existed and all application loaded at startup.
> It will simplify delivering application updates to slow remote targets. I can 
> just upload small tanker files and load it seamlessly because its really fast.
> And without image saves no corrupt images due to something bad at middle of 
> image save.
>
> Hi Denis. I want to say a couple of things about this. First, you are not the 
> only one wanting this. In fact, that scenario is one of the reasons we are 
> investing a lot of time in the infrastructure:
>
> 1) Pavel Krivanek has been working a lot in making the image more modular, 
> being able to cleanly unload and reload packages. This was the first step.
> 2) Jannik Laval continue that effort trying to remove lots of cyclic 
> dependencies between packages.
> 3) Guillermo Polito started to work in the bootstrap. He is now able to 
> bootstrap images from scratch (contrary to Pavel's PharoKernel where he was 
> unloading packages).
> 4) Esteban Lorenzano is working on a new ConfigurationOfPharo that will let 
> you take a kernel/bootstraped/minimal image and load just the packages you 
> want.
> 5) Camilo Bruni, Martin Dias, Guillermo Polito, and Toon Verwaest have been 
> working in a new class builder based on layouts. The "old ClassBuilder" is 
> really difficult to maintain, understand, fix, etc. When you load packages, 
> the class builder takes an important role. Therefore, they were working in a 
> new class builder, which, from my point of view, is way better, 
> object-oriented, tested, etc.
> 6) Martin Dias and Me were working in Tanker, a tool to export/import 
> packages of code using Fuel without Compiler.
>
> So.as you can see there is/was a lot of work going on related to what you 
> need :)  It is not 100% ready, but we are getting there.
>
> Cheers,
>
>
> Best regards,
> Denis
>
>
>
>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-project] How to try Shapes and Gaucho?

[Fernando Olivero]

Hi Denis, I'm actively working on Shapes/Gaucho, but not having the
time to finally polish it to release has held me back in doing so.

The repos are closed for now, until i release them.

Shapes is not "production" ready, unless you are willing to work on
it. Meaning that Gaucho is the sole user for now. It's much more
simpler than using Morphic though(at the expense of loosing some
features, which were never used by the way).  What it gives you is:

1) Vector graphics, its based on Athens.
2) Customizable shapes using a kind of CSS.
3) Shapes always deal with a local coordinate system, no matter were
they're placed in the top/down hierarchy within the scene
4)  simpler Event handling based on message passing (instead of
MorphicEvents), a reified  display and peripherals,
5) An non-overlapping scheme, with snowplowing.
6) No GLOBALS, such as World & ActiveHand.
6) etc...

What's preventing me from releasing it now, is that the
MultipleLinesTextEditor based on Cairo/Pango isnt 100% finished, so
you can type and edit multiple lines of text, and methods. I'm working
on it.



Fernando

On Fri, Sep 28, 2012 at 11:31 PM, Denis Kudriashov  wrote:
> Hello
>
> ss3 repo for Shapes and Gaucho closed for reading or maybe empty.
> So is it possible to get it somewhere? maybe there is prepared image?
>
> Actually I gather migrate our applications to last Pharo and use latest 
> achievemens like fuel and tanker.
> And of course I want vector graphics for user interface by athens.
> And I very very excited about shapes which gives clean and powerfull morphic 
> replacement (Am I right?)
>
> But to understand amount of work for such big changes I should see shapes 
> livelly. I need code.
>
> Best regards,
> Denis

Re: [Pharo-project] [Seaside] Re: change n same words in browser with one action

[Fernando Olivero]

Hi,

maybe in Pharo some of these keyboard shortcuts were removed (for
now), but providing the same operations via pop-up menus doesn't make
it a modal UI. One could argue that remembering and triggering
keyboard shortcuts simply avoids showing the menu at all, at the
expense of a big VI-like learning  curve .

The community behind Pharo does not want  modes in the UI!

Of course for power users, remembering tons of shortcuts might be
better (not for me though), but there are plans to add default and
customizable keybindings ( using the work of Guille Polito).

Fernando



On Fri, Sep 28, 2012 at 9:40 PM, Chris Muller  wrote:
>> yes, exactly like this: http://wiki.squeak.org/squeak/900
>>
>> Bert Freudenberg added the following:
>>
>> Tip: You do not have to perform a "find" for the "replace" to work.
>> Just select a word you want to have replaced, overtype it with your
>> new word, and hit (ctrl-j). Very handy for renaming variables.
>>
>> This would be perfect.
>
> You should not expect that -- Pharo used to have it but it was removed
> in favor of a more mainstream editor look-and-feel -- so that it be
> would more attractive to new users.  Command+J / Control+J are just
> two of several powerful code-editing capabilities Pharo originally
> inherited from Squeak, along with my other favorites Command+E =
> Exchange the last two selections and Command+[, (, {, or | = Surround
> the highlighted text with that bracket-type pair.  (not sure if those
> are still there in Pharo).
>
> Pharo favors _familiarity_ for new users somewhat at the cost of
> productivity for its experienced users.  It somewhat resembles eclipse
> -- with pop-up dialogs and a seemingly "modal" philosophy.  Squeak, by
> constrast, has kept pushing the "simple-but-powerful" philosphy of its
> IDE to near extremes.  While it's less familiar for new uesrs, once
> learned, general navigation and editing require _far fewer_ gestures.
>

Re: [Pharo-project] Learnable Programming

[Fernando Olivero]

AWESOME! its nice to hear that most of the ideas in Dan's article from
the 81: Design principles behind Smalltalk [1], finally made it
elsewhere. The first paragraph resembles the first part of the
article.


Goubier:  Athens needs Cairo, which needs NB. Cairo can be compiled
for 32/64 bits, i belive Igor ships VMs with Cairo built as an
universal library. NB, works for 32 and 64 bits (i've believe Camilo
was working on this). The problem is the Cog VM, its only 32 bits.

Fernando

[1]http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html
On Thu, Sep 27, 2012 at 10:12 AM, Goubier Thierry
 wrote:
> It's a bit out of subject, but does Athens works on a Linux 64bits system ?
>
> Thierry
>
> Le 27/09/2012 09:59, Stéphane Ducasse a écrit :
>> Indeed the key point for our community is how can we create the 
>> infrastructure to
>> be able to provide nice output and interactive.
>>
>> This is why Athens needs clients.
>> Now if nobody cares about Athens then it will get out slower than we want.
>>
>> Beside the text everything else is working.
>> I'm trying to understand how I can help igor and one task is to convert the 
>> current morph drawOn: on athensDrawOn: method.
>> I will keep the examples we will produce once I will sit with igor.
>>
>> Stef
>>
>>
>> On Sep 27, 2012, at 9:22 AM, Goubier Thierry wrote:
>>
>>> Cool!
>>>
>>> There are some very nice program flow representations in them. I'll have a 
>>> look if I can display Jejak traces that way, and maybe explore the use of 
>>> Roassal for this.
>>>
>>> Thierry
>>>
>>> Le 26/09/2012 21:59, Sven Van Caekenberghe a écrit :
 This is _very_ interesting and _very_ welll presented:

 http://worrydream.com/LearnableProgramming/

 Keep on reading, it keeps on getting better towards the end.

 Sven

 --
 Sven Van Caekenberghe
 http://stfx.eu
 Smalltalk is the Red Pill



>>>
>>>
>>> --
>>> Thierry Goubier
>>> CEA list
>>> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
>>> 91191 Gif sur Yvette Cedex
>>> France
>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
>>>
>>
>>
>>
>>
>
>
> --
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
>

Re: [Pharo-project] [Vm-dev] Re: The roadmap aka fight plan to make image control host window

[Fernando Olivero]

thanks for the info igor.

maybe we could plug customized UI handlers for different devices, with
different "raw" events. It would make coding and managing each of
them, a lot simpler than now.


Fernando


On Wed, Sep 26, 2012 at 2:14 PM, Igor Stasenko  wrote:
> On 26 September 2012 13:12, Fernando Olivero  wrote:
>> Igor, i agree 100% percent with you!
>>
>> VM shouldn't have all the responsibility of handling a "single UI window".
>>
>> I've tried in the past to look at VM code, which handles this
>> responsibility and change it, (no UI handling in the VM) ..but it
>> proved to be a difficult task! We need a simpler,
>> cleaner VM,   pluggable  UI handling would be awesome!.
>>
>> Do we need the pointer or Null at all in the VM? Cant the io handling
>> be done completely separate from the VM? A native app for each
>> platform, or something built using NB.
>>
>
> This is highly platform-specific.
> The ioProcessEvents called by VM during interrupt , so,
> platform-specific code can
> use it to signal any pending external events.
> Interrupts is also used by scheduler to switch to another process when
> something happens (like socket has new data to read, semaphore
> signaled etc).
> So, if VM won't support interrupts it will be highly problematic to
> support green threading execution model.
> And, of course, an interrupt is naturally a well-defined safe point in
> VM execution.
> So it is logical to have an entry point there, where plugin(s) can
> hook-in and add own custom event handling procedure,
> without need for patching a single global ioProcessEvents() function
> over and over again.
>
> If at some point you'll have two independent modules (plugins) in VM
> which want to put own custom handling code there,
> you can always do it like following pseudocode:
>
> (during plugin initialization)
> oldHandler := ioProcessEvents.
> ioProcessEvents := &myHandler.
>
> (during call )
> myHandler
>self doMyHandling.
>call oldHandler
>
>
> Now, of course it is a question, how often you may need that: a module
> which adds own custom handler for VM interrupt.
> Maybe we don't need that much flexibility? But do others see other way
> of freeing VM from assumptions and tight coupling with
> different parts of system?
>
> --
> Best regards,
> Igor Stasenko.

Re: [Pharo-project] [Vm-dev] Re: The roadmap aka fight plan to make image control host window

[Fernando Olivero]

Igor, i agree 100% percent with you!

VM shouldn't have all the responsibility of handling a "single UI window".

I've tried in the past to look at VM code, which handles this
responsibility and change it, (no UI handling in the VM) ..but it
proved to be a difficult task! We need a simpler,
cleaner VM,   pluggable  UI handling would be awesome!.

Do we need the pointer or Null at all in the VM? Cant the io handling
be done completely separate from the VM? A native app for each
platform, or something built using NB.

Fernando


On Wed, Sep 26, 2012 at 2:57 AM, Igor Stasenko  wrote:
> Remember, Andreas added a nice new feature into (at least) windows
> VMs, where upon startup it showing a splash image?
> By reading a .bmp file and delaying rest of process by couple seconds.
> That maybe useful. But what if tomorrow, my customer will want to keep
> showing it, till user click on it?
> What you will do? Right! Go and hack VM. And what if he will want to
> show splash and progress bar while loading/initializing stuff? Another
> shitloads of code into VM?
> And something fantastic, what if customer would like to use different
> image format for splash screen, png, jpeg? And what if we would like
> to automatically download the splash image from web site before
> showing it?
>
> So, where is the end of this? When you will finally say "enough", we
> need proper window management in image?
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-project] instVarNames vs instVarNamed:

[Fernando Olivero]

...makes me envy the simplicity of SELF!

Fernando

On Mon, Sep 24, 2012 at 10:38 AM, Igor Stasenko  wrote:
> On 24 September 2012 08:53, Stéphane Ducasse  
> wrote:
>>
>> On Sep 24, 2012, at 1:56 AM, Igor Stasenko wrote:
>>
>>> okay, i found what is wrong with first post (didn't read carefully).
>>>
>>> The instVarNames is a class-side protocol i.e. part of a class behavior,
>>> while instVarNamed: is an instance-side protocol i.e. "hackishly
>>> access to instance variable with given name"
>>
>> Yes this is exactly my point.
>> I think that there is a protocol missing for class to be consistent.
>>
> err, what is missing? class is an object, and using #instVarNamed: on
> them is perfectly fine.
>
>
>>> So, this is ok:
>>> Nautilus class instVarNames
>>>->  #('maxSize' 'cachedLastClasses' 'groups')
>>>
>>> And this is ok too:
>>>
>>> Nautilus instVarNamed: 'groups'
>>>worked
>>>
>>> because Nautilus is an instance of its metaclass.
>>>
>>> But this is wrong, since 'Nautilus class' is an instance of Metaclass,
>>> and metaclass doesn't have 'groups' variable.
>>>
>>> Nautilus class instVarNamed: 'groups'
>>>-> error
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-project] An idea about visual feedback in Athens

[Fernando Olivero]

Igor,  the way i've handled the "mouse hit" issue, is by asking the
parent shape (morph) to take care of a mouse hit, and let him handle
or forward the hit.

The topmost shape are sent the mouseDown: aLocalPoint, then each shape
can choose to react, if its a composite shape or by a specific
behavior.

The topmost shape is always "a scene shape", which knows the bounds in
global coordinates, then internally it applies local transforms to
eventually get to the inner shape which was hit. The separation
between scene shapes and shapes, allows this mechanism, similar to the
one you propose, to cache the global state.

I prefer this approach, instead of  the "framework" level as you
propose, because is  more of a top-down collaboration, always dealing
with local coordinates. It greatly simplifies the UI framework,
avoiding the messy "god classes" and complex methods you mentioned and
many more in Morphic.


Fernando

On Sun, Sep 2, 2012 at 10:12 AM, Stéphane Ducasse
 wrote:
> Yes we should really refactor this hierarchy.
> We should finish first the event model cleaning at VM/Image border then we 
> work on this one.
>
> On Aug 31, 2012, at 9:21 PM, Igor Stasenko wrote:
>
>> and to give an idea, how current Morphic doing that, a starting point is
>> MorphicEventDispatcher
>>
>> personally, i find this code too complex to understand, given heavy
>> use of case statements and branches.
>>
>> But i figured out, that this method:
>>
>>
>> dispatchEvent: anEvent with: aMorph
>>   "Dispatch the given event for a morph that has chosen the receiver to
>> dispatch its events. The method implements a shortcut for repeated
>> dispatches of events using the same dispatcher."
>>   anEvent type == lastType ifTrue:[^self perform: lastDispatch with:
>> anEvent with: aMorph].
>>   "Otherwise classify"
>>   lastType := anEvent type.
>>   anEvent isMouse ifTrue:[
>>   anEvent isMouseDown ifTrue:[
>>   lastDispatch := #dispatchMouseDown:with:.
>>   ^self dispatchMouseDown: anEvent with: aMorph]].
>>   anEvent type == #dropEvent ifTrue:[
>>   lastDispatch := #dispatchDropEvent:with:.
>>   ^self dispatchDropEvent: anEvent with: aMorph].
>>   anEvent isWindowEvent ifTrue:[
>>   lastDispatch := #dispatchWindowEvent:with:.
>>   ^self dispatchWindowEvent: anEvent with: aMorph].
>>   lastDispatch := #dispatchDefault:with:.
>>   ^self dispatchDefault: anEvent with: aMorph
>>
>> ---
>>
>> actually can be replaced by one-liner:
>>
>> dispatchEvent: anEvent with: aMorph
>>morph := aMorph.
>>   ^ anEvent sentTo: self
>>
>> .. yeah.. my favorite thing:  double-dispatch.
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>

Re: [Pharo-project] Changing permanently the mouse cursor

[Fernando Olivero]

HandMorph is the software cursor, which now only gets drawn when the
hand  is drawn, which only happens when its carrying a morph.

Cursor is the hardware cursor, the one handled by the VM and drawn
most of the time.

IMO, we need to change the VM, to not handle the hardware cursor
anymore, so we can rely only on the software cursor. So we can always
be sure that HandMorph or (the equivalent using other UI framework) is
the cursor being drawn.

Fernando

On Mon, Sep 17, 2012 at 12:00 PM, Igor Stasenko  wrote:
> On 17 September 2012 11:40, Hilaire Fernandes
>  wrote:
>> Hello,
>>
>> One can change temporary the mouse cursor with something like:
>>
>> World currentHand showTemporaryCursor: ThemeIcons eyedropperIcon
>>
>> But depending on the widgets the mouse is over, its cursor may change again.
>>
>> Beside hacking the HandMorph class is there a way to change permanently
>> the mouse cursor?
>>
> Good question.
>
> AFAIK, last time i seen it in code, the point where cursor is
> controlled is in Cursor class.
> Hand resets cursor by sending #normal message to  it.
>
> It would be really nice to have changeable default cursor.
> The Cursor global used everywhere in system. We should find the way
> how to avoid that.
>
>> Thanks
>>
>> Hilaire
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-project] GSoC - Package management with Fuel

[Fernando Olivero]

Hi Martin,

Thanks for reporting on the results, i wasnt aware of such a cool project.

Looking forward to use it, instead of what we have now, i remember how
fast it was to load objects in Visual Smalltalk.

Saludos,
Fernando

On Fri, Aug 24, 2012 at 10:01 AM, Martin Dias  wrote:
> Hi
>
> This week has ended Google Summer of Code program 2012. I have to
> thank Marcus and Carlos Ferro, my mentors, as well as Mariano,
> Guille Polito, Camillo Bruni, and others, who collaborated in
> different ways during these three months. Also thank, of course,
> to Carla and Janko... and Google ;)
>
> The main purpose of this mail is to summarize the work done for my
> project, named "Package management with Fuel" [1][2].
>
> Tools for managing code in Pharo export classes, traits, and methods
> as series of source definitions, which then import by evaluating them
> with the compiler. This is basically how FileOut/FileIn or Monticello
> works. This is slow on large pieces of code, so if you want to install
> a big package, you need a lot of time compiling it. Why should you
> compile it again, given that it was all compiled when you exported the
> package? The bytecodes will be the same again, you know... If you just
> could load the Classes and Compiled Methods instead of compiling it
> all again, you can save time.
>
> With this goal in mind, I started working in FuelPackageLoader[4] (now
> Tanker[3]), a prototype we wrote last year, which already exports and
> imports packages without using any compiler. But it has two important
> issues: it wasn't capable of export source code, and it wasn't able to
> tolerate class-shape changes in hierarchies (ie, a change on inst vars
> in a external superclass). So, we decided to start from scratch with a
> new prototype, code name Carbono. The idea was to reify how FileOut
> and FileIn are done, but storing binary information so that
> compilation can be avoided.
>
> In a nutshell, Carbono stores a package into two files:
> - A sources file, imitating the traditional FileOut chunk format.
> - A binary file, where uses Fuel[5] to serialize a series of code
> definitions. Each of them knows the position in the sources file where
> its source code counterpart is. For example, a class definition knows
> the position of its comment (in the case it exists), and a method
> definition knows the position of its source code.
>
> A basic example, to export a couple of classes:
>
> TAExport new
> binariesOn: aBinaryStream
> sourcesOn: aTextStream;
> behaviors: {ClassA. ClassB};
> methods: {};
> initializeClasses: true;
> run.
>
> which then you can import with:
>
> TAImport new
> binariesFrom: aBinaryStream
> sourcesFrom: aTextStream;
> run.
>
> Anyway, you can also choose to:
>  - export only binaries or only sources
>  - import only binaries (source code can be decompiled)
>  - import only sources (via #fileIn)
>
> Mariano Martinez Peck worked a lot on it, fixing bugs, and especially
> optimizing it A LOT, so I hope you will enjoy his demonstration this
> Monday on ESUG Innovation Awards. Seems that he could export Seaside,
> Pier and Magritte, and import them in another image, with source code,
> and just in a few seconds ;) Also, some ultra confidential WikiLeaks
> revealed that he could export almost all Pharo packages, and import
> them in a kernel image, all with source codes but without using the
> compiler :)
>
> Note1: Tolerating class-shape changes in hierarchies is not yet done,
> but it should in some days. So far, the only strategy when a change is
> detected will be to recompile methods, but it may be more
> sophisticated in a not-so-far future.
>
> Note2: Although finally it was not strictly necessary, Guillermo
> Polito and me wrote tests for a new ClassBuilder. It is part of Slot,
> a kind of reification of objects layout made by Toon Verwaest and
> Camillo Bruni. It is too long to explain it here, but the thing is
> that was not an easy job, and we hope it will be integrated in Pharo.
>
> This is a work in progress, but you can install and try it on latest
> Pharo 2.0, evaluating:
>
> Gofer it
> squeaksource3: 'PharoTaskForces';
> package: 'Slot';
> package: 'SlotTests';
> load.
> (Smalltalk at: #SlotVirus) perform: #spread.
> Gofer it
> squeaksource3: 'PharoTaskForces';
> package: 'SlotsClassBuilderIntegration';
> load.
> Gofer new
> smalltalkhubUser: 'marianopeck' project: 'Tanker';
> package: 'ConfigurationOfTanker';
> load.
> (Smalltalk at: #ConfigurationOfTanker) loadBleedingEdge.
> Gofer new
> squeaksource: 'FuelExperiments';
> package: 'Carbono';
> package

Re: [Pharo-project] New Text Completion suggestions

[Fernando Olivero]

Igor, as usual your true object-oriented thinking helps us see a better path...

We need a customized UI interaction for Smalltalk, instead of asking
for TEXT editors devised for a different setup. What's missing is a
Smalltalk method shape(morph, etc...), highly customized for
editing/navigating statements written in the Smalltalk syntax. (
unless you want to code the methods using the workspace.)

We can still preserve cmd-c for copy, and cmd-v for paste...IMO it's
not about inventing a new set of  keyboard shortcuts, but more about
manipulating objects at the right level of abstraction.

Saludos,
Fernando


On Fri, Aug 24, 2012 at 1:40 AM, Igor Stasenko  wrote:
> On 24 August 2012 01:19, Eliot Miranda  wrote:
>>
>>
>> On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko  wrote:
>>>
>>> (a bit orthogonal)
>>> i don't understand why we cannot have own, consistent set which is good
>>> for us?
>>> vim, emacs..
>>
>>
>> better use sets which are already extremely familiar than invent yet another
>> set.  to those of us who use these editors (and we are legion) these sets
>> have long become almost subconscious to use.
>>
>
> i know that.. i also came to squeak from outside..
> but as we say in Ukraine: don't enter others sanctuary with own
> code(set of rules).
>
>>> why this is so important ? Those editors were not written for editing
>>> smalltalk code in mind..
>>> they are best suited for big, hundreds lines of code, files..
>>
>>
>> they're the two most popular editors of their type.  lots of people use them
>> for other languages without IDE support.  They provide convenient power
>> features such as pattern replacement.  Not often I find myself filing out
>> Smalltalk code and editing it with vim (sadly I've never learned emacs).
>>
> me too.. i never learned emacs. So, maybe i am completely ignorant and can't 
> see
> why it is so important to have it there.. But then, i don't
> understand, why most of editors i know
> never had emacs/vim key bindings as option? Are they completely stupid? Huh?
>
> So, you know, if we follow that logic.. hey we don't have a unix command 
> line..
> so maybe we should add an option: either workspace or command line?
> and then introduce nice terminal emulation with prompt, users and .bashrc ..
> ahh.. what the hell.. lets replicate whole unix environment.. imagine
> how many happy users will join us then!
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

[Fernando Olivero]

Yes, caching is what i do in my system. It would amazing that Pharo
implements such a caching scheme for methods and their ast .

If you evaluate the code i pasted before, you will note that it does
preserve the actual source.

RBMethodNode>>source
 ^ source

instead, RBMethodNode>>formtattedSource , vists the ast to return the source.

Fernando


On Thu, Aug 16, 2012 at 4:20 PM, Levente Uzonyi  wrote:
> On Thu, 16 Aug 2012, Fernando Olivero wrote:
>
>> NICE! I would say lets go for it, 120MB is nothing nowadays. The IDE
>> could be simplied and be more powerful.
>
> Let's be a bit more realistic. The current garbage collector is choking if
> you add 100 MB of small objects to your image. Caching the recently
> accessed ASTs sounds like a better idea.
>
>>
>> For example, in gaucho i'm using the ast for pretty printing of the
>> source, and for styling unsed variables differently, etc...
>
> You didn't answer yet if RB's AST can reproduce the exact same source
> string or not.
>
>
> Levente
>
>>
>>
>> Fernando
>>
>> On Thu, Aug 16, 2012 at 9:35 AM, Marcus Denker  
>> wrote:
>>>
>>> On Aug 16, 2012, at 9:32 AM, Fernando Olivero  
>>> wrote:
>>>
>>>> I've been using RB, which allows to recreate on demand the ast, but in
>>>> my system i cached those values.
>>>>
>>>>
>>>> ast := RBParser parseMethod: 'parsingAMethod
>>>>   | yeah |
>>>>   yeah := self doesAMethodNode rememberitssource.
>>>>   yeah
>>>>   ifTrue:[ ^ #hurray]'.
>>>>
>>>> ast source.
>>>> ast formattedCode.
>>>>
>>>> ast := (Object>>#at:) parseTree.
>>>> ast source.
>>>> ast formattedCode
>>>>
>>>>
>>>> Regarding the memory usage, in my system only the methods which have a
>>>> "method shape" opened in the IDE, store their ast, thus i cannot
>>>> provide numbers of the overhead. But why should one extra object more
>>>> per method be a problem?
>>>>
>>>
>>> It's not one object... it's a tree. I did once a system that stored the AST 
>>> for each method
>>> (uncompressed) in addition to what is there now (CompiledMethod).
>>> The system was 120MB instead of 20MB. (based on Squeak 3.9)
>>>
>>> Which means, even then smaller than Eclipse ;-)
>>>
>>> Marcus
>>>
>>>
>>> --
>>> Marcus Denker -- http://marcusdenker.de
>>>
>>
>>

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

[Fernando Olivero]

NICE! I would say lets go for it, 120MB is nothing nowadays. The IDE
could be simplied and be more powerful.

For example, in gaucho i'm using the ast for pretty printing of the
source, and for styling unsed variables differently, etc...


Fernando

On Thu, Aug 16, 2012 at 9:35 AM, Marcus Denker  wrote:
>
> On Aug 16, 2012, at 9:32 AM, Fernando Olivero  wrote:
>
>> I've been using RB, which allows to recreate on demand the ast, but in
>> my system i cached those values.
>>
>>
>> ast := RBParser parseMethod: 'parsingAMethod
>>   | yeah |
>>   yeah := self doesAMethodNode rememberitssource.
>>   yeah
>>   ifTrue:[ ^ #hurray]'.
>>
>> ast source.
>> ast formattedCode.
>>
>> ast := (Object>>#at:) parseTree.
>> ast source.
>> ast formattedCode
>>
>>
>> Regarding the memory usage, in my system only the methods which have a
>> "method shape" opened in the IDE, store their ast, thus i cannot
>> provide numbers of the overhead. But why should one extra object more
>> per method be a problem?
>>
>
> It's not one object... it's a tree. I did once a system that stored the AST 
> for each method
> (uncompressed) in addition to what is there now (CompiledMethod).
> The system was 120MB instead of 20MB. (based on Squeak 3.9)
>
> Which means, even then smaller than Eclipse ;-)
>
> Marcus
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

[Fernando Olivero]

I've been using RB, which allows to recreate on demand the ast, but in
my system i cached those values.


ast := RBParser parseMethod: 'parsingAMethod
| yeah |
yeah := self doesAMethodNode rememberitssource.
yeah
ifTrue:[ ^ #hurray]'.

ast source.
ast formattedCode.

ast := (Object>>#at:)   parseTree.
ast source.
ast formattedCode


Regarding the memory usage, in my system only the methods which have a
"method shape" opened in the IDE, store their ast, thus i cannot
provide numbers of the overhead. But why should one extra object more
per method be a problem?


Fernando


On Wed, Aug 15, 2012 at 11:10 PM, Levente Uzonyi  wrote:
> On Wed, 15 Aug 2012, Fernando Olivero wrote:
>
>> Hi, great point Marcus.  I was wondering why cant a compiled method
>> know the "ast" that generated it?
>
> Would you store all ASTs in memory all the time or recreate it every time
> on demand?
>
>>
>> It would ease the queries + manipulation, in the tools a lot!
>>
>> CompiledMethod>>getSourceReplacingSelectorWith: aSelector
>> 
>>
>> would be instead:
>>
>> CompiledMethod>>withSelector: aSelector
>>  ^ (self ast withSelector: aSelector) source.
>
> Is there an implementation of AST that can reproduce the exact same source
> code?
>
>
> Levente
>
>>
>>
>> I've been using an AST, instead of the CompiledMethods directly for
>> this reason, to deal with more expressive power.
>>
>> Fernando
>>
>> On Tue, Aug 14, 2012 at 2:56 PM, Marcus Denker  
>> wrote:
>>>
>>> On Aug 14, 2012, at 2:01 PM, Mariano Martinez Peck  
>>> wrote:
>>>
>>>> Hi guys. Today, there is a part of the system coupled with Compiler. Issue 
>>>> is: http://code.google.com/p/pharo/issues/detail?id=6110
>>>>
>>>> Now, if you see the method:
>>>>
>>>> getSourceReplacingSelectorWith: newSelector
>>>>   | oldKeywords newKeywords args newSelectorWithArgs source 
>>>> oldSelector s |
>>>>   source := self sourceCode.
>>>>   oldSelector := self parserClass new parseSelector: source.
>>>>   oldSelector = newSelector ifTrue: [ ^ source ].
>>>>   oldKeywords := oldSelector keywords.
>>>>   newKeywords := (newSelector ifNil: [self defaultSelector]) keywords.
>>>>   [oldKeywords size = newKeywords size] assert.
>>>>   args := (self methodClass parserClass new
>>>>   parseArgsAndTemps: source string notifying: nil) copyFrom: 1 
>>>> to: self numArgs.
>>>>   newSelectorWithArgs := String streamContents: [:stream |
>>>>   newKeywords withIndexDo: [:keyword :index |
>>>>   stream nextPutAll: keyword.
>>>>   stream space.
>>>>   args size >= index ifTrue: [
>>>>   stream nextPutAll: (args at: index); 
>>>> space]]].
>>>>   s := source string readStream.
>>>>   oldKeywords do: [ :each | s match: each ].
>>>>   args isEmpty ifFalse: [ s match: args last ].
>>>>   ^newSelectorWithArgs trimBoth, s upToEnd
>>>>
>>>> The 2 magic lines are:
>>>>
>>>> oldSelector := self parserClass new parseSelector: source.
>>>>   oldSelector = newSelector ifTrue: [ ^ source ].
>>>>
>>>> So, why we cannot just replace "self parserClass new parseSelector: 
>>>> source." with "self selector". Well, I think (talking with Guille) this 
>>>> ONLY because of Trait transformation/aliases that associates a selector 
>>>> with a method of a different selector.
>>>>
>>>> If this is the case, it means that 99% of the cases,"oldSelector = 
>>>> newSelector ifTrue: [ ^ source ].  "  is true. Because those aliases are 
>>>> only used in one trait in all the image ().
>>>>
>>>> So...if that is the case, can't we get the oldSelector from elsewhere  
>>>> rather than needing to use the Compiler to get the selector from the 
>>>> source code ?
>>>>
>>> As we now encode the selector in the CompiledMethod itself, this can be 
>>> relaced with
>>>
>>> oldSelector := self selector.
>>>
>>>
>>> But what you have left is the arguments...
>>>
>>> args := (self methodClass parserClass new
>>> parseArgsAndTemps: source string notifying: nil) copyFrom: 
>>> 1 to: self numArgs.
>>>
>>> The only way to get the the argument names (temps) of a method is to 
>>> compile the source... no way around it.
>>>
>>> (I personally think this is another example why bytecode as the model for 
>>> reflection is just wrong)
>>>
>>>
>>> Marcus
>>>
>>>
>>> --
>>> Marcus Denker -- http://marcusdenker.de
>>>
>>>
>>
>>

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

[Fernando Olivero]

Hi, great point Marcus.  I was wondering why cant a compiled method
know the "ast" that generated it?

It would ease the queries + manipulation, in the tools a lot!

CompiledMethod>>getSourceReplacingSelectorWith: aSelector


would be instead:

CompiledMethod>>withSelector: aSelector
  ^ (self ast withSelector: aSelector) source.


I've been using an AST, instead of the CompiledMethods directly for
this reason, to deal with more expressive power.

Fernando

On Tue, Aug 14, 2012 at 2:56 PM, Marcus Denker  wrote:
>
> On Aug 14, 2012, at 2:01 PM, Mariano Martinez Peck  
> wrote:
>
>> Hi guys. Today, there is a part of the system coupled with Compiler. Issue 
>> is: http://code.google.com/p/pharo/issues/detail?id=6110
>>
>> Now, if you see the method:
>>
>> getSourceReplacingSelectorWith: newSelector
>>   | oldKeywords newKeywords args newSelectorWithArgs source oldSelector 
>> s |
>>   source := self sourceCode.
>>   oldSelector := self parserClass new parseSelector: source.
>>   oldSelector = newSelector ifTrue: [ ^ source ].
>>   oldKeywords := oldSelector keywords.
>>   newKeywords := (newSelector ifNil: [self defaultSelector]) keywords.
>>   [oldKeywords size = newKeywords size] assert.
>>   args := (self methodClass parserClass new
>>   parseArgsAndTemps: source string notifying: nil) copyFrom: 1 
>> to: self numArgs.
>>   newSelectorWithArgs := String streamContents: [:stream |
>>   newKeywords withIndexDo: [:keyword :index |
>>   stream nextPutAll: keyword.
>>   stream space.
>>   args size >= index ifTrue: [
>>   stream nextPutAll: (args at: index); space]]].
>>   s := source string readStream.
>>   oldKeywords do: [ :each | s match: each ].
>>   args isEmpty ifFalse: [ s match: args last ].
>>   ^newSelectorWithArgs trimBoth, s upToEnd
>>
>> The 2 magic lines are:
>>
>> oldSelector := self parserClass new parseSelector: source.
>>   oldSelector = newSelector ifTrue: [ ^ source ].
>>
>> So, why we cannot just replace "self parserClass new parseSelector: source." 
>> with "self selector". Well, I think (talking with Guille) this ONLY because 
>> of Trait transformation/aliases that associates a selector with a method of 
>> a different selector.
>>
>> If this is the case, it means that 99% of the cases,"oldSelector = 
>> newSelector ifTrue: [ ^ source ].  "  is true. Because those aliases are 
>> only used in one trait in all the image ().
>>
>> So...if that is the case, can't we get the oldSelector from elsewhere  
>> rather than needing to use the Compiler to get the selector from the source 
>> code ?
>>
> As we now encode the selector in the CompiledMethod itself, this can be 
> relaced with
>
> oldSelector := self selector.
>
>
> But what you have left is the arguments...
>
> args := (self methodClass parserClass new
> parseArgsAndTemps: source string notifying: nil) copyFrom: 1 
> to: self numArgs.
>
> The only way to get the the argument names (temps) of a method is to compile 
> the source... no way around it.
>
> (I personally think this is another example why bytecode as the model for 
> reflection is just wrong)
>
>
> Marcus
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>

Re: [Pharo-project] Question about RPackage (bug?)

[Fernando Olivero]

You're right! But notice that the RPackage logic of one to one mapping
with categories, only
breaks   when it  only provides extension methods as in the case of
'AST-Core' and 'RPackage'.

| p |
p := RPackageOrganizer default packageNamed: 'AST-Core'.
( p extensionMethods size = 2 ) & ( p definedClasses size = 0 )

Only then, maybe this is a bug?


On Thu, Aug 9, 2012 at 1:52 PM, Mariano Martinez Peck
 wrote:
>
>
> On Thu, Aug 9, 2012 at 1:25 PM, Fernando Olivero 
> mailto:fernando.oliv...@usi.ch>> wrote:
> Hi Mariano,
>
> I've been using RPackage so i stumbled on the same "problem".
>  RPackage maps System Categories (one to one), thus your problem
> happens because there's no category named 'RPackage'.
>
>
> But for the rest it works. For example:
>
> (RPackageOrganizer default packageNamed: 'AST-Core')
>
> And there is no category 'AST-Core'.
>
> Moreover, I have just discovered that if I evaluate:  RPackageOrganizer 
> initialize.
> Then it appears :)
>
>
> For example evaluate  (RPackageOrganizer default packageNamed: 
> 'RPackage-Core')
>
> Saludos,
> Fernando
>
> On Thu, Aug 9, 2012 at 12:24 PM, Mariano Martinez Peck
> mailto:marianop...@gmail.com>> wrote:
>> (MCWorkingCopy allManagers  collect: [:p | p package name] ) includes: 
>> 'RPackage' -> true
>>
>> (RPackageOrganizer default packageNamed: 'RPackage') -> KeyNotFound
>>
>> bug?
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-project] color problem?

[Fernando Olivero]

Hi Esteban,

It's a matter of percentage, meaning that you can chose an percentage
of r, of g, and of b, and by default the values go from 0.0 to 1.0.

If you want to use 255 as the max (as 1.0), then do  as Gary posted.

Fernando



On Thu, Aug 9, 2012 at 4:32 PM, Esteban Lorenzano  wrote:
> why this is logic? shouldn't be enough just using r:g:b:alpha:?
>
> sorry, my graphics skills are close to zero so... no idea if what I'm saying 
> has any sense :)
>
> On Aug 9, 2012, at 11:44 AM, "Gary Chambers"  
> wrote:
>
>> Color values range from 0.0 to 1.0 use
>>
>> (Color r: 255 g: 255 b: 122 range: 255) alpha: 1.0
>>
>> instead ;-)
>>
>> Regards, Gary
>>
>> - Original Message - From: "Esteban Lorenzano" 
>> To: "Pharo-project@lists.gforge.inria.fr Development" 
>> 
>> Sent: Wednesday, August 08, 2012 5:05 PM
>> Subject: [Pharo-project] color problem?
>>
>>
>>> Hi,
>>>
>>> try:
>>>
>>> Color r: 255 g: 255 b: 122 alpha: 255.
>>>
>>> AFAIK, that should bring a yellow color. And it is not.
>>> Anyone knows why?
>>>
>>> Esteban
>>>
>>
>>
>
>

Re: [Pharo-project] Question about RPackage (bug?)

[Fernando Olivero]

Hi Mariano,

I've been using RPackage so i stumbled on the same "problem".
 RPackage maps System Categories (one to one), thus your problem
happens because there's no category named 'RPackage'.

For example evaluate  (RPackageOrganizer default packageNamed: 'RPackage-Core')

Saludos,
Fernando

On Thu, Aug 9, 2012 at 12:24 PM, Mariano Martinez Peck
 wrote:
> (MCWorkingCopy allManagers  collect: [:p | p package name] ) includes: 
> 'RPackage' -> true
>
> (RPackageOrganizer default packageNamed: 'RPackage') -> KeyNotFound
>
> bug?
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-project] R.I.P. SystemChangeNotifier

[Fernando Olivero]

Goodbye Pen, ImageSegment, FileDirectory, and now
SystemChangeNotifier! NICE work you guys! (Soon, we will even have an
image without Morphic at all... )

We need to make a graveyard (a fun web page for the Pharo site? ) for
all deceased objects, so we don't forget them, and why we chose to let
them die...

Fernando

On Tue, Aug 7, 2012 at 3:46 PM, Mariano Martinez Peck
 wrote:
>
>
> On Tue, Aug 7, 2012 at 12:50 PM, Esteban Lorenzano 
> mailto:esteba...@gmail.com>> wrote:
> Hi,
>
> Today we finally finish the removal of SystemChangeNotifier. This is a big 
> step forward to unify all system events into announcements. Current 
> notification center is named "SystemAnnouncer" and all events has been 
> reified into more meaningful announcements...
> This operation was really hard because is like changing the heart of a living 
> person :)
> For 99.99% of users, this will be absolute transparent, but there are some 
> cases where maybe some problems emerge. Please, take this into account to 
> migrate your code soon.
> Don't wait until is to late!
>
>
> m did you remove #doSilently: ?
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-project] 'self halt' safety net

[Fernando Olivero]

What about a Nautilus plugin, that allows browsing all the methods
that send #halt, #flag:,#log:? (the "development" messages).

Since finding all the halts, doesn't seem something that needs to be
performed all the time, an optional Nautilus plugin would suffice.


Fernando

On Sat, Aug 4, 2012 at 3:02 PM, Sean P. DeNigris  wrote:
>
> Mariano Martinez Peck wrote
>>
>>> Another thought, are there any plans for a "breakpoint" facility, so that
>>> I don't dirty a package by only inserting 'self halt' to aid debugging.
>> it already exists. Right click on a method -> Add breakpoint
>>
>
> I, too would love to have the features you suggest. However, as it stands, I
> would strongly advise against using breakpoints (someone definitely let me
> know, maybe this is not still a problem in 2.0). In my experience, they are
> incredibly buggy. Historically:
> * if you add a breakpoint in one tool, and try to disable it in another, it
> may still be active; and who remembers what tool they enabled it in???
> * there is very little feedback as to when a breakpoint is enabled
>   - no icon in the browsers
>   - the menu item was "toggle breakpoint" instead of dynamically "enable"
> vs. "disable"
>
> In all, I found it very confusing to figure out when a breakpoint was
> enabled, and how to disable. Of course, anyway, these are not breakpoints as
> typically offered by an IDE, which can be attached to any statement, but
> only at the method level.
>
> Cheers,
> Sean
>
>
>
> --
> View this message in context: 
> http://forum.world.st/self-halt-safety-net-tp4643012p4643070.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

Re: [Pharo-project] Customizing the Caret of a PluggableTextMorph

[Fernando Olivero]

Hi Phil. Excellent summary of the current mess!

Yes, TextMorphs are the "views" , Editors handle the
insertion/selection/menu logic, and Paragraphs lay out the text.

I've replaced Paragraph, with Pango Layouts to reuse a more
customizable layout engine, until some kind soul rewrites completely
Paragraph (and friends) to be as easy to use (and powerfull) as Pango
(which i doubt it will happen in the next decade).


Denis, unfortunately i had to handle other stuff related to my phd,
and still couldn't release Gaucho/Shapes, I'm working on it now again.
Here's a presentation i gave @ the pharo conf [1]. Glad to hear that
you want to try to use it for Presently, will be out soon.

[1] 
http://app.sliderocket.com:80/app/FullPlayer.aspx?id=fcff251e-29cd-49eb-89b3-e33349139ddf




On Fri, Jul 20, 2012 at 4:26 PM, p...@highoctane.be  wrote:
> So, there is the damn caret drawing code:
>
> Paragraph>>displaySelectionInLine: line on: aCanvas
> | leftX rightX w caretColor |
> selectionStart ifNil: [^self]. "No selection"
> aCanvas isShadowDrawing ifTrue: [ ^self ]. "don't draw selection with shadow"
> selectionStart = selectionStop
> ifTrue:
> ["Only show caret on line where clicked"
>
> selectionStart textLine ~= line ifTrue: [^self]]
> ifFalse:
> ["Test entire selection before or after here"
>
> (selectionStop stringIndex < line first
> or: [selectionStart stringIndex > (line last + 1)]) ifTrue: [^self]. "No 
> selection on this line"
> (selectionStop stringIndex = line first
> and: [selectionStop textLine ~= line]) ifTrue: [^self]. "Selection ends on 
> line above"
> (selectionStart stringIndex = (line last + 1)
> and: [selectionStop textLine ~= line]) ifTrue: [^self]]. "Selection begins on 
> line below"
> leftX := (selectionStart stringIndex < line first
> ifTrue: [line ]
> ifFalse: [selectionStart ])left.
> rightX := (selectionStop stringIndex > (line last + 1) or:
> [selectionStop stringIndex = (line last + 1)
> and: [selectionStop textLine ~= line]])
> ifTrue: [line right]
> ifFalse: [selectionStop left].
> selectionStart = selectionStop
> ifTrue:
> [rightX := rightX + 1.
> w := self caretWidth.
> caretRect := (leftX-w) @ line top corner: (rightX+w)@ line bottom.
> self showCaret ifFalse:[^self].
> caretColor := self insertionPointColor.
> 1 to: w
> do:
> [:i |
> "Draw caret triangles at top and bottom"
>
> aCanvas fillRectangle: ((leftX - w + i - 1) @ (line top + i - 1)
> extent: ((w - i) * 2 + 3) @ 1)
> color: caretColor.
> aCanvas fillRectangle: ((leftX - w + i - 1) @ (line bottom - i)
> extent: ((w - i) * 2 + 3) @ 1)
> color: caretColor].
> aCanvas fillRectangle: (leftX @ line top corner: rightX @ line bottom)
> color: caretColor]
> ifFalse:
> [caretRect := nil.
> aCanvas fillRectangle: (leftX @ line top corner: rightX @ line bottom)
> color: self selectionColor]
>
>
>
>
> Paragraph class>>insertionPointColor has the color. I was fed up of blue, 
> turned it red :-)
> This one is hardcoded and could take a hint from the selection color 
> twiceDarker for example.
>
> Phil
>
> 2012/7/20 Denis Kudriashov mailto:dionisi...@gmail.com>>
> Hello
>
> 2012/7/20 Fernando Olivero 
> mailto:fernando.oliv...@usi.ch>>
> Hi Sean, you can take a look at Athens-PangoCairo (in squeaksource).
>
> Using NativeBoost, i'm using the Pango layout library [1], and the
> Pango-Cairo binding [2],  to avoid laying out text using the outdated
> (and messy) stuff in the image.
>
> Check out the classes: ParagraphDescription & AthensPangoCairoParagraph.
>
> I'm using them as the basis for the TextShape,LabelShape, and
> EditableTextShape in Shapes / Gaucho ( using TextEditor,
> SingleLineEditor ).
>
> Maybe somebody can do the same for Morphic? use Pango to layout the
> text, and code a new TextMorph on top of it?
>
> How I can try your code?
> Do you have ready image to play with it?
>
> I am very interested with clean and simple alternative to morphic. I want it 
> for Presenty framework.
>
> (But I really like morphic as live user interface environment)
>
> Best regards,
> Denis
>
>
>
>
>
>
> --
> Philippe Back
> Dramatic Performance Improvements
> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: 
> p...@highoctane.be<mailto:p...@highoctane.be> | Web: http://philippeback.eu | 
> Blog: http://philippeback.be
>
> High Octane SPRL
> rue cour Boisacq 101
> 1301 Bierges
> Belgium

Re: [Pharo-project] [ANN] Alternative view of a system browser

[Fernando Olivero]

Hi, nice work. Looking forward to play with it.
Is it similar to the Newspeak browser? Where methods expand in place.

Fernando


On Wed, Jul 18, 2012 at 7:36 AM, Stéphane Ducasse
 wrote:
> I do not have a connection to look at it.
> But I LOVE the idea. I love the idea that we can prototype fast new tools and 
> rethink how processes….
> Spec is one way to enable that. For example I love the GlamourInspector and 
> it would be great to rewrite it with Spec.
> Thanks a lot.
> Stef
>
> On Jul 17, 2012, at 3:12 PM, Goubier Thierry wrote:
>
>> I believe that the traditional SystemBrowser of Smalltalk of old has been 
>> made unusable by the amount of code (and structure) you find in today's 
>> Smalltalk images.
>>
>> So this is to show you an alternative, a different way to browse through 
>> packages / classes and methods and code. This is Spec-based.
>>
>> https://picasaweb.google.com/lh/photo/ic_fRnBXXdyqbiJ5NRP9YtMTjNZETYmyPJy0liipFm0?feat=directlink
>>
>> What is missing / targeted ?
>> * Drag and drop reorganisation of the tree as preferred / or as package / 
>> category reuse.
>> * A good search facility in the tree. It is already keyboard navigation 
>> friendly (since the tree view is).
>> * Most / All menu methods of a complete System Browser. I'm planning on 
>> reusing the OmniBrowser command structure as much as possible (to make it 
>> faster).
>> * Funny ideas on how to use the tree structure : group / selection display, 
>> queries, metrics ...
>> ** There is probably a lot more to be done here, but it would probably 
>> require Mondrian or other graph visualisation tools.
>>
>> Expect the code sometime by the end of the week, in a Pharo 2.0 / Pharo 1.4 
>> version.
>>
>> Thierry
>> --
>> Thierry Goubier
>> CEA list
>> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
>> 91191 Gif sur Yvette Cedex
>> France
>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
>>
>>
>
>

Re: [Pharo-project] Customizing the Caret of a PluggableTextMorph

[Fernando Olivero]

Hi Sean, you can take a look at Athens-PangoCairo (in squeaksource).

Using NativeBoost, i'm using the Pango layout library [1], and the
Pango-Cairo binding [2],  to avoid laying out text using the outdated
(and messy) stuff in the image.

Check out the classes: ParagraphDescription & AthensPangoCairoParagraph.

I'm using them as the basis for the TextShape,LabelShape, and
EditableTextShape in Shapes / Gaucho ( using TextEditor,
SingleLineEditor ).

Maybe somebody can do the same for Morphic? use Pango to layout the
text, and code a new TextMorph on top of it?

Fernando

[1] http://developer.gnome.org/pango/stable/pango-Layout-Objects.html
[2] http://developer.gnome.org/pango/stable/pango-Cairo-Rendering.html
On Wed, Jul 18, 2012 at 7:28 AM, Stéphane Ducasse
 wrote:
>
> On Jul 16, 2012, at 9:38 PM, Sean P. DeNigris wrote:
>
>> For VimPharo, I want to have a different cursor depending on whether a tool
>> is in insert or normal mode.
>>
>> I tried a handful of ways, but they all failed or worked
>> partially/inconsistently. Here's some of them:
>> * add the state to the paragraph, but the entire paragraph gets replaced
>> during the life of the tool, so the state gets lost
>> * add the state to the editor, but the situation is the same
>> * add the state to PluggableTextMorph, override and access it from
>> TextMorphForEditView>>updateFromParagraph. This was an extreme PITA and got
>> me very acquainted with the emergency evaluator. It "worked", but only after
>> using the arrows a bit.
>>
>> Does anyone have any idea where I might hook in?
>>
>> I find the whole text system very confusing. What the heck does a
>> paragraph know about insertion points?? A view has one paragraph object,
>> even if there are several paragraphs (as understood by the rest of humanity
>> as a block of text with breaks between the adjoining ones. Editors and
>> Paragraphs are thrown out and replaced on a whim. I'm finding it very hard
>> to understand and modify
>
> I got burned by that when I worked on my botanics env….
> it was terrible.
>
>>
>> Thanks,
>> Sean
>>
>> --
>> View this message in context: 
>> http://forum.world.st/Customizing-the-Caret-of-a-PluggableTextMorph-tp4640245.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>
>
>

Re: [Pharo-project] Putting Cairo in the VM?

[Fernando Olivero]

Yes, i was wondering about that.

The NB OpenGL example worked when reopening a saved image.

Stef, if you want to reopen the crashing image, just remove the cairo
lib from the plugins folder. Then open it and delete all example
morphs and save.

Fernando


On Fri, Jul 6, 2012 at 11:22 AM, Igor Stasenko  wrote:
> On 5 July 2012 21:44, Stéphane Ducasse  wrote:
>> Igor I rebuild everything based on 1.2.1 and it loads and the example works
>> now as soon as I save the image I cannot open it anymore.
>>
> do you saving image with sample morph open?
>
> i think i omitted the reinitialization procedure which shoul happen
> when session changes..
>
>> So I will work why the image of fernando.
>>
>> Stef
>>
>> On Jul 5, 2012, at 8:14 PM, Stéphane Ducasse wrote:
>>
>>> Gofer it
>>>url: 'http://www.squeaksource.com/Athens';
>>>  package: 'ConfigurationOfAthens';
>>>   load.
>>>
>>> was loading the wrong one…. probably an old version. I hate fuzzy scripts. 
>>> losing time for nothing..
>>> Now retrying with everything again.
>>>
>>> stef
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-project] Athens Mac os doc like animation

[Fernando Olivero]

Hi Stef, here's a link to a working Athens + Cairo image.

http://dl.dropbox.com/u/22215979/PharoImages/Athens-04-07.zip

I've recommend following the steps posted by Igor, to have the latests version.
But this one is generated from the build and repo of yesterday + the
path to the library hack.

Fernando

On Thu, Jul 5, 2012 at 11:56 AM, Igor Stasenko  wrote:
> On 5 July 2012 11:55, Igor Stasenko  wrote:
>> On 5 July 2012 11:48, Igor Stasenko  wrote:
>>> On 5 July 2012 11:02, Stéphane Ducasse  wrote:

 On Jul 5, 2012, at 9:53 AM, Igor Stasenko wrote:

> ok..
>
> 1. fixed FFI dependency, just try to load same config of athens over again
> (if in fresh image)..
>
> 2. the plugin search path change was not committed, we checked that
> with Esteban,
> neither NBCog, nor vanilla Cog VMs see freetype plugin..
> lets wait till jenkins produce a new VM builds…

 Ok I really want to have fun with athens so tell when this is ok :)

 Stef
>>>
>>> ok, the latest VM build seems to be working.
>>> what i did:
>>> 1. download VM [
>>> https://ci.lille.inria.fr/pharo/view/NativeBoost/job/NB-Cog-Mac-Cocoa/28/artifact/NBCog.zip
>>> ]
>>> 2. downloaded 2.0 image
>>> 3. loaded ConfigurationOfAthens
>>>
>>> 4. doit: ConfigurationOfAthens loadVersion: '1.2.1'
>>>
>>> 5: doit: AthensFlakeDemo new openInWorld
>>>
>>> and it works , as in here: https://vimeo.com/45137985
>>>
>>> :)
>>>
>> and then i loaded
>> ConfigurationOfXMLSupport from config browser,
>
> ah, yes.. missing "loaded Athens-SVG" step here ...
>
>
>> filed in the
>> ASAnimation.st
>> then
>> ASZoomerMorph.st
>>
>> and then did
>>
>> ASZoomerMorph new
>> svg: 'Coche_ok_verte.svg' zoom: 0.1;
>> openInWorld
>>
>> and here what i got (see attached)
>>
>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-project] Athens Mac os doc like animation

[Fernando Olivero]

Oops, replace NBCog in the path by  NBCog.app , as in:

TCairoLibrary class>>nbLibraryNameOrHandle
  (Smalltalk vm vmPath asFileReference / 'NBCog.app' /
'Contents'/ 'MacOS' / 'Plugins' / 'libcairo.2.dylib'  ) fullName
   .


On Wed, Jul 4, 2012 at 10:27 PM, fernando.oliv...@usi.ch
 wrote:
> To properly run the example, besides installing Athens you need to
> have Athens-SVG and XML Support.
>
> "SVG support 
> ---"
> Gofer it
> url: 'http://www.squeaksource.com/MetacelloRepository';
>   package: 'ConfigurationOfXMLSupport';
> load.
> (Smalltalk globals classNamed: 'ConfigurationOfXMLSupport') load.
>
> Gofer it
> squeaksource: 'Athens';
> package: 'Athens-SVG';
> load.
>
>
> To fix the previous mentioned library path modification install this,
> as temporal HACK, before Igors get's the change to review it.
>
>
> TCairoLibrary class>>nbLibraryNameOrHandle
> (NativeBoost platformId = NativeBoostConstants linux32PlatformId) 
> ifTrue: [
> ^ '/usr/lib/libcairo.so'
> ].
> (NativeBoost platformId = NativeBoostConstants mac32PlaformId) 
> ifTrue: [
> ^
> (Smalltalk vm vmPath asFileReference / 'NBCog' / 'Contents'/ 'MacOS' /
> 'Plugins' / 'libcairo.2.dylib'  ) fullName
> ].
> self error: 'define your own path'
>
>
>
>
> On Wed, Jul 4, 2012 at 10:04 PM, fernando.oliv...@usi.ch
>  wrote:
>> Hi Stef, surely is happening because the path to the Cairo Lib changed.
>>
>> It used to in the MacPorts path, but now Igor is shipping NB vm's with Cairo.
>> So we should change the following method.
>>
>> TCairoLibrary>>nbLibraryNameOrHandle
>> (NativeBoost platformId = NativeBoostConstants linux32PlatformId) 
>> ifTrue: [
>> ^ '/usr/lib/libcairo.so'
>> ].
>> (NativeBoost platformId = NativeBoostConstants mac32PlaformId) 
>> ifTrue: [
>> ^ '/opt/local/lib/libcairo.2.dylib'
>> ].
>> self error: 'define your own path'
>>
>> Fixing it now, will send the new method .
>>
>> Fernando
>>
>> On Wed, Jul 4, 2012 at 7:26 PM, Stéphane Ducasse
>>  wrote:
>>>
>>>
>>>
>>> ASZoomerMorph new
>>> svg: 'Coche_ok_verte.svg' zoom: 0.1;
>>> openInWorld
>>>
>>> Alex this is the example I was talking to you about.
>>>
>>>
>>> Igor this is strange when I executed the athens image in which you hacked 
>>> the animation on the latest
>>> NBCog vm it crashes.
>>>
>>> Do you know where I can find the latest Athens friendly vm?
>>>
>>> Stef
>>
>

Re: [Pharo-project] Athens Mac os doc like animation

[Fernando Olivero]

To properly run the example, besides installing Athens you need to
have Athens-SVG and XML Support.

"SVG support 
---"
Gofer it
url: 'http://www.squeaksource.com/MetacelloRepository';
  package: 'ConfigurationOfXMLSupport';
load.
(Smalltalk globals classNamed: 'ConfigurationOfXMLSupport') load.   

Gofer it
squeaksource: 'Athens';
package: 'Athens-SVG';
load.


To fix the previous mentioned library path modification install this,
as temporal HACK, before Igors get's the change to review it.


TCairoLibrary class>>nbLibraryNameOrHandle
(NativeBoost platformId = NativeBoostConstants linux32PlatformId) 
ifTrue: [
^ '/usr/lib/libcairo.so'
].
(NativeBoost platformId = NativeBoostConstants mac32PlaformId) ifTrue: [
^
(Smalltalk vm vmPath asFileReference / 'NBCog' / 'Contents'/ 'MacOS' /
'Plugins' / 'libcairo.2.dylib'  ) fullName
].
self error: 'define your own path'




On Wed, Jul 4, 2012 at 10:04 PM, fernando.oliv...@usi.ch
 wrote:
> Hi Stef, surely is happening because the path to the Cairo Lib changed.
>
> It used to in the MacPorts path, but now Igor is shipping NB vm's with Cairo.
> So we should change the following method.
>
> TCairoLibrary>>nbLibraryNameOrHandle
> (NativeBoost platformId = NativeBoostConstants linux32PlatformId) 
> ifTrue: [
> ^ '/usr/lib/libcairo.so'
> ].
> (NativeBoost platformId = NativeBoostConstants mac32PlaformId) 
> ifTrue: [
> ^ '/opt/local/lib/libcairo.2.dylib'
> ].
> self error: 'define your own path'
>
> Fixing it now, will send the new method .
>
> Fernando
>
> On Wed, Jul 4, 2012 at 7:26 PM, Stéphane Ducasse
>  wrote:
>>
>>
>>
>> ASZoomerMorph new
>> svg: 'Coche_ok_verte.svg' zoom: 0.1;
>> openInWorld
>>
>> Alex this is the example I was talking to you about.
>>
>>
>> Igor this is strange when I executed the athens image in which you hacked 
>> the animation on the latest
>> NBCog vm it crashes.
>>
>> Do you know where I can find the latest Athens friendly vm?
>>
>> Stef
>

Re: [Pharo-project] Athens Mac os doc like animation

[Fernando Olivero]

Hi Stef, surely is happening because the path to the Cairo Lib changed.

It used to in the MacPorts path, but now Igor is shipping NB vm's with Cairo.
So we should change the following method.

TCairoLibrary>>nbLibraryNameOrHandle
(NativeBoost platformId = NativeBoostConstants linux32PlatformId) 
ifTrue: [
^ '/usr/lib/libcairo.so'
].
(NativeBoost platformId = NativeBoostConstants mac32PlaformId) ifTrue: [
^ '/opt/local/lib/libcairo.2.dylib'
].
self error: 'define your own path'

Fixing it now, will send the new method .

Fernando

On Wed, Jul 4, 2012 at 7:26 PM, Stéphane Ducasse
 wrote:
>
>
>
> ASZoomerMorph new
> svg: 'Coche_ok_verte.svg' zoom: 0.1;
> openInWorld
>
> Alex this is the example I was talking to you about.
>
>
> Igor this is strange when I executed the athens image in which you hacked the 
> animation on the latest
> NBCog vm it crashes.
>
> Do you know where I can find the latest Athens friendly vm?
>
> Stef

Re: [Pharo-project] Problem with FileSystem primitives in latest Pharo2.0

[Fernando Olivero]

ok, now is working just fine.  I've downloaded the latest CogVM, NB
VM, and Pharo2.0 from Jenkins.

Although i'm 100% sure i was using the downloaded vm's, i deleted the
old vm's in my machine also, as Camilo suggested. Couldnt figure out
why it wasnt working for me previously, but its fixed now!


Thanks for the help,

Fernando

On Wed, Jul 4, 2012 at 4:19 PM, Camillo Bruni  wrote:
> Fernando be sure to get rid of all the old vms on OSX :P
> OSX is particularly good in finding an old version somewhere that does not 
> properly work :P
>
> On 2012-07-04, at 10:54, Fernando Olivero wrote:
>
>> Yes, i'm using the latest.
>>
>> VM:  https://ci.lille.inria.fr/pharo/job/Cog-VM/Architecture=32,OS=mac/58/
>>
>> Sven, are you using Mac OSX ?
>>
>> Esteban replied that's a known bug, (unexisting file giving tue on
>> #exists) maybe its implied that'solely for the Mac ?
>>
>> I will do an unit test to capture this issue.
>>
>> Fernando

Re: [Pharo-project] Putting Cairo in the VM?

[Fernando Olivero]

Nice work! Thanks Igor.
Will be a lot easier now to release Athens related projects.

Fernando

On Wed, Jul 4, 2012 at 2:15 PM, Igor Stasenko  wrote:
> Ok, the build #27 is built a first VM with cairo library. Congratulations! :)
>
> https://ci.lille.inria.fr/pharo/view/NativeBoost/job/NB-Cog-Mac-Cocoa/27/
>
>
> Check it out.
>
> Please note that all plugins and libraries is now in
> .app/Contents/MacOS/Plugins
> not in
> .app/Contents/Resouces
>
> (the plugin search logic is changed accordingly)
>

Re: [Pharo-project] Problem with FileSystem primitives in latest Pharo2.0

[Fernando Olivero]

Yes, i'm using the latest.

VM:  https://ci.lille.inria.fr/pharo/job/Cog-VM/Architecture=32,OS=mac/58/

Sven, are you using Mac OSX ?

Esteban replied that's a known bug, (unexisting file giving tue on
#exists) maybe its implied that'solely for the Mac ?

I will do an unit test to capture this issue.

Fernando


On Wed, Jul 4, 2012 at 10:44 AM, Sven Van Caekenberghe  wrote:
>
> On 04 Jul 2012, at 09:51, Fernando Olivero wrote:
>
>> But i found that the following is working incorrectly:
>>
>> (FileSystem disk workingDirectory / 'unexistingFileForTesting.txt')
>> asFileReference exists = true
>
> Hmm, that would be a serious problem, I am using that as well,
>
> (FileSystem disk workingDirectory / 'unexistingFileForTesting.txt') 
> exists
>
> gives false for me ;-)
>
> And this works as well:
>
> 2 timesRepeat:[ (FileSystem disk workingDirectory /
> 'unexistingFileForTesting.txt') delete ].
>
> Is there a unit test covering your problem ?
> If not, there should be.
>
> Sven

Re: [Pharo-project] Problem with FileSystem primitives in latest Pharo2.0

[Fernando Olivero]

I wanted to provide the following fix to the previous problem: to
check wether a file exists before deleting it.

FileSystem>>delete: aResolvable
aResolvable asFileReference exists ifTrue:[ store delete: (self
resolve: aResolvable) ]

But i found that the following is working incorrectly:

(FileSystem disk workingDirectory / 'unexistingFileForTesting.txt')
asFileReference exists = true


Esteban, maybe this is the cause of problems? Was it like this before?


Fernando


On Wed, Jul 4, 2012 at 9:42 AM, fernando.oliv...@usi.ch
 wrote:
> Hi Sven, yes is working.
>
> I found the error. Try evaluating the code WHEN the file is un-existing.
>
> 2 timesRepeat:[ (FileSystem disk workingDirectory /
> 'unexistingFileForTesting.txt') delete ].
>
> I will try to fix it,
>
> The initial problem was that monticello is trying to delete an
> un-existing mcz file in the package-cache.
> Strange that nobody else had this problem before.
>
> Fernando
>
>
> On Wed, Jul 4, 2012 at 9:32 AM, fernando.oliv...@usi.ch
>  wrote:
>> Yes, i'm using the latest VM's from Jenkins.
>>
>> I've tried with both Cog and NB vm's.
>>
>> It appears to be related to the (internal) FilePlugin, did esteban
>> make changes to it?
>>
>> Surely this happened to somebody else? When trying to load/merge/commit ?
>>
>> Fernando
>>
>>
>> On Wed, Jul 4, 2012 at 9:28 AM, Marcus Denker  wrote:
>>> Are you using a current VM from Jenkins?
>>>
>>> I think FileSystem needs some fixes in the Vm File plugin...
>>>
>>> On Jul 4, 2012, at 9:23 AM, Fernando Olivero wrote:
>>>
>>>> Hi, i found an error in the latest Pharo2.0 build, at least in OSX ,
>>>> that prevents from using Gofer and monticello.
>>>>
>>>> Its related to the FileSystem primitives, when trying to delete a file.
>>>>
>>>> To reproduce evaluate the following code ( change 'PharoDebug.log' for
>>>> any existing file in the same directory as the image).
>>>>
>>>> | path |
>>>> path := FileSystem disk workingDirectory.
>>>> p := FilePluginPrims new .
>>>> p  deleteDirectory: (path / 'PharoDebug.log') fullName.
>>>>
>>>>
>>>> Any idea why?
>>>>
>>>> Thanks,
>>>> Fernando
>>>>
>>>
>>> --
>>> Marcus Denker -- http://marcusdenker.de
>>>
>>
>

Re: [Pharo-project] Problem with FileSystem primitives in latest Pharo2.0

[Fernando Olivero]

Hi Sven, yes is working.

I found the error. Try evaluating the code WHEN the file is un-existing.

2 timesRepeat:[ (FileSystem disk workingDirectory /
'unexistingFileForTesting.txt') delete ].

I will try to fix it,

The initial problem was that monticello is trying to delete an
un-existing mcz file in the package-cache.
Strange that nobody else had this problem before.

Fernando


On Wed, Jul 4, 2012 at 9:32 AM, fernando.oliv...@usi.ch
 wrote:
> Yes, i'm using the latest VM's from Jenkins.
>
> I've tried with both Cog and NB vm's.
>
> It appears to be related to the (internal) FilePlugin, did esteban
> make changes to it?
>
> Surely this happened to somebody else? When trying to load/merge/commit ?
>
> Fernando
>
>
> On Wed, Jul 4, 2012 at 9:28 AM, Marcus Denker  wrote:
>> Are you using a current VM from Jenkins?
>>
>> I think FileSystem needs some fixes in the Vm File plugin...
>>
>> On Jul 4, 2012, at 9:23 AM, Fernando Olivero wrote:
>>
>>> Hi, i found an error in the latest Pharo2.0 build, at least in OSX ,
>>> that prevents from using Gofer and monticello.
>>>
>>> Its related to the FileSystem primitives, when trying to delete a file.
>>>
>>> To reproduce evaluate the following code ( change 'PharoDebug.log' for
>>> any existing file in the same directory as the image).
>>>
>>> | path |
>>> path := FileSystem disk workingDirectory.
>>> p := FilePluginPrims new .
>>> p  deleteDirectory: (path / 'PharoDebug.log') fullName.
>>>
>>>
>>> Any idea why?
>>>
>>> Thanks,
>>> Fernando
>>>
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>

Re: [Pharo-project] Problem with FileSystem primitives in latest Pharo2.0

[Fernando Olivero]

Yes, i'm using the latest VM's from Jenkins.

I've tried with both Cog and NB vm's.

It appears to be related to the (internal) FilePlugin, did esteban
make changes to it?

Surely this happened to somebody else? When trying to load/merge/commit ?

Fernando


On Wed, Jul 4, 2012 at 9:28 AM, Marcus Denker  wrote:
> Are you using a current VM from Jenkins?
>
> I think FileSystem needs some fixes in the Vm File plugin...
>
> On Jul 4, 2012, at 9:23 AM, Fernando Olivero wrote:
>
>> Hi, i found an error in the latest Pharo2.0 build, at least in OSX ,
>> that prevents from using Gofer and monticello.
>>
>> Its related to the FileSystem primitives, when trying to delete a file.
>>
>> To reproduce evaluate the following code ( change 'PharoDebug.log' for
>> any existing file in the same directory as the image).
>>
>> | path |
>> path := FileSystem disk workingDirectory.
>> p := FilePluginPrims new .
>> p  deleteDirectory: (path / 'PharoDebug.log') fullName.
>>
>>
>> Any idea why?
>>
>> Thanks,
>> Fernando
>>
>
> --
> Marcus Denker -- http://marcusdenker.de
>

[Pharo-project] Problem with FileSystem primitives in latest Pharo2.0

[Fernando Olivero]

Hi, i found an error in the latest Pharo2.0 build, at least in OSX ,
that prevents from using Gofer and monticello.

Its related to the FileSystem primitives, when trying to delete a file.

To reproduce evaluate the following code ( change 'PharoDebug.log' for
any existing file in the same directory as the image).

| path |
path := FileSystem disk workingDirectory.
p := FilePluginPrims new .
p  deleteDirectory: (path / 'PharoDebug.log') fullName.


Any idea why?

Thanks,
Fernando

Re: [Pharo-project] Encodings, Charsets, converters... streams?

[Fernando Olivero]

Cant we throw them all? And later add one by one when (if at all...) needed?

Fernando

On Wed, Jun 27, 2012 at 5:34 PM, Guillermo Polito
 wrote:
> I've spent 3 hours on trying to understand deeply the Multilingual mess, but 
> I'm dying in the process...  It mixes environments with charsets... Some 
> charsets and converters are for really old OS versions... Sometimes it uses 
> unicode, some times not... argggdsdsa
>
> On Wed, Jun 27, 2012 at 5:25 PM, Stéphane Ducasse 
> mailto:stephane.duca...@inria.fr>> wrote:
> ok but how can we build a concrete roadmap.
> What are the steps that we can take and perform one by one.
>
> Stef
>
> On Jun 27, 2012, at 3:11 PM, Henrik Sperre Johansen wrote:
>
>> On 25.06.2012 18:06, Denis Kudriashov wrote:
>>> Hello.
>>>
>>> What is responsibility of environments (russian, japanese) classes.
>>> Why its needed? Why converter classes not enough?
>>>
>>> For example, I can write russian text at workspace without setting any 
>>> specific russian environment. I only need specific fonts for this.
>>>
>> Novadays, they can be used to read number/date printing policies, decide 
>> which translation package to use, etc. Basically what you'd expect from an 
>> OS locale, but more limited in capabilities.
>>
>> The part linked to charsets and encodings seem to me an anachronism from 
>> when the OS's used different encodings based on the selected environment 
>> though. (so files would be read and written automatically  with the correct 
>> (non-unicode) encoding, and potentially displayed using a different bitmap 
>> font through selection using leadingChar)
>>
>>> 2012/6/25 Guillermo Polito 
>>> mailto:guillermopol...@gmail.com>>
>>> Hi guys,
>>>
>>> I'm trying to understand the Multilingual packages to get things a bit more 
>>> reorganized. This way we can start to have a simpler and understandable 
>>> kernel. So,
>>>
>>> - We have all environments(greek, chinese, japanese, korean, russian...) in 
>>> the same package.  Each environment has it's associated charset, and text 
>>> converter, which are in different packages.  Also, each text converter has 
>>> a table of conversions between unicode and the encoding. But all converters 
>>> are together, and all charsets are together.
>>>
>>> What about putting related things together? I mean, japanese converter with 
>>> japanese environment with japanese charset in one package. Same with 
>>> russian, korean, chinese...  Does it make sense?  This way we should be 
>>> able to unload one of them if we do not really need it.
>>>
>>
>>> - MultiByteFileStream and MultiByteBinaryOrTextStream are inside 
>>> Multilingual-TextConversion?  Even, they do the same on top of a file or a 
>>> memory stream of bytes (or they say so in the comment :^D )...
>>>
>>> What about merging them? using a decorator? They have a lot in common... :/ 
>>>  Put them in a different package?
>> They are not neatly composed.
>> Trying to merge them so the methods work with a file and bytearray/string 
>> backend equivalently would probably only make things even worse.
>> Using a decorator would be hard, since the MultiByteFileStream method 
>> implementations use alot of its inherited behaviour.
>>
>> As for putting them in a different package, sure you can peddle crap around 
>> all you want, but that doesn't make it stink any less.
>>>
>>> - Just curious. ImmPlugin is working or shipped with vms? Not for macos, 
>>> because there is no macos implementation. Then, the class comment says:
>>>
>>> "On Windows, the plugin is not provided in the shipped VM's, and its 
>>> current whereabouts are uncertain.
>>>
>>> On Unix, the only implemented behaviour is setting the position when 
>>> over-the-spot precomposition of characters is the current mode.
>>>
>>> In the VM, the mode is chosen to the first available valid mode returned by 
>>> the X Server, so whether this is actually relevant at all depends on the X 
>>> Server."
>>>
>>> So, does someone use it and see value on keeping it?
>>
>> Sure, there is value in neatly integrating OS input methods for composed 
>> characters.
>>
>> Whether that belongs in a plugin of it's own, and whether what the plugin 
>> currently offers justifies its existence, is a different question, which I 
>> guess the removal was the answer to. :)
>>
>> To find any potential actual users, I guess you'd have to find a pharo app 
>> localized to the eastern hemisphere and have it ask their linux users if 
>> they appreciate it/if it works.
>> That, or a developer from the same area who codes in his native language 
>> (which will be hard I think, given arbitrary tool constraints wrt message 
>> names etc.)
>>
>> Cheers,
>> Henry
>
>
>

Re: [Pharo-project] LanguageEnvironment>>#setUsePangoFlag

[Fernando Olivero]

I would remove it, it's a reminisce of Sophie surely. They used to
have Pango and Cairo bindings.

Fernando

On Mon, Jun 25, 2012 at 5:16 PM, Guillermo Polito
 wrote:
> And this method is funny :) because with a clean startup list it does not 
> work:
>
> LanguageEnvironment>>initialize
>    "LanguageEnvironment initialize"
>
>    Smalltalk addToStartUpList: LanguageEnvironment after: DiskStore.
>    Smalltalk addToStartUpList: DiskStore after: LanguageEnvironment.
>
> Even better, the language environment initialize does not need DiskStore... 
> so Maybe we can simplify it a lot.
>
> On Mon, Jun 25, 2012 at 4:26 PM, Guillermo Polito 
> mailto:guillermopol...@gmail.com>> wrote:
> Hi!
>
> is that hook used by anybody?  The only implementor does ^self...  And that 
> method has no changed since 2009.
>

Re: [Pharo-project] How to correctly remove a package for everywhere?

[Fernando Olivero]

Seems that removing a package does not imply removing the included
classes?Maybe this should be changed?

With RPackage is understandable, since its just a layer on top of the
system.You have to explicitly register/deregister packages.

Fernando


On Wed, Jun 20, 2012 at 10:24 PM, Mariano Martinez Peck
 wrote:
> well, I don't know what the hell happened, but a workaround I think it is
>
> DataStream removeFromSystem.
> RPackageOrganizer  default unregisterPackageNamed: #'System-Object Storage'.
>
> On Wed, Jun 20, 2012 at 10:19 PM, Mariano Martinez Peck 
> mailto:marianop...@gmail.com>> wrote:
> So removing 'System-Object Storage' didn't work. I did:
>
> ScriptLoader new deletePackageNamed: 'System-Object Storage'.
>
> Now the MCWorkingCopy is removed (I don't see the package in Monticello 
> Browser), but I can still browse the class DataStream, and the package is 
> available from Nautilus.
>
> Now if I do:
>
> RPackageOrganizer  default unregisterPackageNamed: #'System-Object Storage'
>
> I don't see the package in Nautilus, but the class "DataStream" is still 
> alive. I can do "DataStream name -> #DataStream" ..et...when I browse it with 
> Nautilus I don't see the class but the category _UnpackagedPackage..
>
> so...how the hell can I remove this package and class from everywhere in the 
> system?
>
> thanks
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-project] Worskpace question

[Fernando Olivero]

I don't think its related to the processes priority.

Can you provide more code of the  DrGeoCanvas>>#initialize ?

Because, the following works just fine, by evaluating the first two
lines, or the complete script.

m := Morph new.
m openInWorld.

m color: Color red.
m extent: 300@300.

m delete

Fernando

On Wed, Jun 20, 2012 at 12:16 PM, Hilaire Fer
nandes  wrote:
> DHello,
>
> I have a question regarding the Workspace when you execute code from there.
>
> Let me show with an example:
>
> I want to execute code instantiating an empty DrGeo sketch (a morph)
> then create programmatically content:
>
>
> |canvas|
> canvas := DrGeoCanvas new.
> canvas segment: 5@4 to: 10@20.
> canvas vector: 0@0 to: 2@2.
> ...
>
> The line with DrGeoCanavas creates and opens a new morph of a DrGeo sketch.
>
> My problem is: the morph only shows up on screen when the whole
> Workspace code is executed. I would like the canvas morph to show up
> when instantiated then get the construction code done step by step in
> the screen.
>
> Is the workspace code executed with higher priority than the user
> interface thread?
>
>
> Thanks
>
> Hilaire
>
> --
> Dr. Geo -- http://www.drgeo.eu
>
>

Re: [Pharo-project] compiled method inherits from Collection?

[Fernando Olivero]

Thanks for the info, its a shame we cant easily change the vm.

Oh well, i should first ask for isCompiledMethod before isCollection now...

Fernando

On Tue, Jun 19, 2012 at 11:34 AM, Marcus Denker  wrote:
>
> On Jun 19, 2012, at 11:28 AM, Fernando Olivero wrote:
>
>> (Object>>#name) isCollection = true
>>
>> Actually is a subclass of ByteArray (instead of collaborating with one).
>>
>> Does this seem strange to anybody else? Is it really needed?
>>
> CompiledMethods are magical.  They are highly optimized for saving space.
> If this is needed in 2012 where even a cellphone has half a gig of RAM is
> something that people are highly opinionated about.
>
> And the special format of CompiledMethod is something the VM knows.
>
> So: any change here means deep VM changes.
>
>        Marcus
>
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>

[Pharo-project] compiled method inherits from Collection?

[Fernando Olivero]

(Object>>#name) isCollection = true

Actually is a subclass of ByteArray (instead of collaborating with one).

Does this seem strange to anybody else? Is it really needed?

Fernando

Re: [Pharo-project] What i would like to have instead of progress bar

[Fernando Olivero]

I agree, i've implemented in Gaucho a WaitingShape.

Which resembles the ones found in the web players (the lines in
different angles forming a circle, that rotate an alpha value to
denote passage of time).

w := WaitingShape on: self.
w start.
...
w stop.

I've used it when importing stored sessions.


Fernando

On Fri, Jun 1, 2012 at 2:08 AM, Igor Stasenko  wrote:
> ah, yeah.. one last thing:
> - do not show the progress, in situations when there is no timely
> advance is possible,
> like waiting for server response: just put a notification line.. but
> no stupid empty progress line
> which serves no purpose
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-project] Pharocasts ... updating and screencasts wanted

[Fernando Olivero]

Once i finish with the release of Gaucho, i will commit myself to
produce a cool Athens video.
Around next week.
Fernando

On Thu, May 31, 2012 at 10:53 AM, laurent laffont
 wrote:
> If some people wants write access to Pharocasts tell me.
>
> I follow the mailing list in passive mode - still very busy.
>
> Cheers,
>
> Laurent Laffont
>
> On Thu, May 31, 2012 at 10:22 AM, Torsten Bergmann 
> mailto:asta...@gmx.de>> wrote:
> Hi all,
>
> http://www.pharocasts.com/ is a little bit outdated
> since it still shows Pharo 1.3 instead of 1.4.
> Download linke also goes to 1.3.
>
> Would also be nice if someone can record some new
> screencasts on things like
>
>  - Nautilus
>  - Roassal
>  - Zinc/Zodiac
>  - New Fuel Release with visual debugging support
>  - Ring
>  - FileSystem
>  - NativeBoost
>  - Nagare logging library
>  - Artefact PDF library
>  - Athens
>  - Working with SS3
>  - ...
>
> and send them to Laurent.
>
> Any takers?
>
> Thx
> T.
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>

Re: [Pharo-project] moving Finder up to first level of World menu

[Fernando Olivero]

NICE. Excellent summary, thanks Mariano.

gracias totales!
Fernando
pd: i will start using  Spotlight right away!


On Thu, May 31, 2012 at 10:27 AM, Mariano Martinez Peck
 wrote:
>
>
> On Thu, May 31, 2012 at 10:18 AM, Fernando Olivero 
> mailto:fernando.oliv...@usi.ch>> wrote:
> How i can install/see plugins for Nautilus?
>
>
> http://marianopeck.wordpress.com/2012/05/19/pharo-tips-and-tricks/
>
> cmd+f -> plugin
>
> :)
>
> Fernando
>
> On Thu, May 31, 2012 at 9:44 AM, Stéphane Ducasse
> mailto:stephane.duca...@inria.fr>> wrote:
>>>>
>>>>      Examples than pattern.
>>>>      because Pattern to me measn something else.
>>>
>>> I know :) But some people argue the opposite so I just picked :)
>>>
>>>>
>>>> We should also give us access to update spec and nautilus directly because 
>>>> like that we are not the bottleneck.
>>>
>>> What o you mean ?
>>
>> that you should commit directly your changes to nautilus and spec and that 
>> we do not have to do it.
>> But right now focus on the paper. Can you create a svn repo?
>>
>> Stef
>>
>>>
>>> Ben
>>>
>>>> Stef
>>>>
>>>> On May 30, 2012, at 6:12 PM, Benjamin wrote:
>>>>
>>>>> +1 :)
>>>>>
>>>>> You can also use the finder plugin for Nautilus made by Damien Cassou :)
>>>>>
>>>>> Ben
>>>>>
>>>>> On May 30, 2012, at 11:43 AM, Ben Coman wrote:
>>>>>
>>>>>>
>>>>>> Has any consideration been given to moving World > Tools > Finder up to 
>>>>>> World > Finder.
>>>>>> I find this is core to my work flow and I it is used much more often 
>>>>>> than any of System Browser, Workspace, Test Runner or Monticello Browser 
>>>>>> - and I wonder if anyone finds the same?
>>>>>>
>>>>>> cheers -ben
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-project] moving Finder up to first level of World menu

[Fernando Olivero]

How i can install/see plugins for Nautilus?

Fernando

On Thu, May 31, 2012 at 9:44 AM, Stéphane Ducasse
 wrote:
>>>
>>>      Examples than pattern.
>>>      because Pattern to me measn something else.
>>
>> I know :) But some people argue the opposite so I just picked :)
>>
>>>
>>> We should also give us access to update spec and nautilus directly because 
>>> like that we are not the bottleneck.
>>
>> What o you mean ?
>
> that you should commit directly your changes to nautilus and spec and that we 
> do not have to do it.
> But right now focus on the paper. Can you create a svn repo?
>
> Stef
>
>>
>> Ben
>>
>>> Stef
>>>
>>> On May 30, 2012, at 6:12 PM, Benjamin wrote:
>>>
 +1 :)

 You can also use the finder plugin for Nautilus made by Damien Cassou :)

 Ben

 On May 30, 2012, at 11:43 AM, Ben Coman wrote:

>
> Has any consideration been given to moving World > Tools > Finder up to 
> World > Finder.
> I find this is core to my work flow and I it is used much more often than 
> any of System Browser, Workspace, Test Runner or Monticello Browser - and 
> I wonder if anyone finds the same?
>
> cheers -ben
>


>>>
>>>
>>
>>
>
>

[Pharo-project] Monticello Speedup!

[Fernando Olivero]

Thanks for making Monticello/Gofer 300% faster!

And its non-blocking, now when i commit/merge i dont have to look at
the ceiling for 3 minutes.

Fernando

Re: [Pharo-project] loading athens - a user perspective

[Fernando Olivero]

You shouldnt use Brew, because it cant compile universal binaries.

Athens, with a  cairo backend, uses NativeBoost which needs 32 bit
libraries, because CogGM is targeted to 32 bits.

I also tried with Brew, that's why i found out is hard to instruct
brew to compile universal binaries.

Fernando

On Fri, May 25, 2012 at 12:39 PM, Serge Stinckwich
 wrote:
> On Fri, May 25, 2012 at 4:57 PM, Tudor Girba  wrote:
>> Hi,
>>
>> Here is how to install Athens (I also added this comment to the 
>> ConfigurationOfAthens):
>>
>>
>> 1. Install Cairo on your machine
>> For example, for Mac, you open the terminal and run:
>> sudo port install -f cairo +universal
>>
>> More information can be found here:
>> http://cairographics.org/download/
>>
>>
>> 2. Download the NativeBoost enabled Cog VM from:
>> https://ci.lille.inria.fr/pharo/view/NativeBoost/
>>
>>
>> 3. Get a Pharo image and run:
>> Gofer new
>>        squeaksource: 'Athens';
>>        package: 'ConfigurationOfAthens';
>>        load.
>> (Smalltalk at: #ConfigurationOfAthens) loadDevelopment
>>
>>
>> 4. Play with it. For example:
>> VGTigerDemo runDemo
>
> I install Cairo with brew on mac os x:
> brew install cairo
>
> And I got the following stack trace:
>
>
> 25 May 2012 5:37:03 pm
>
> VM: Mac OS - intel - 1074 - NBCoInterpreter
> NativeBoost-CogPlugin-IgorStasenko.9 uuid:
> 801decd2-0b42-fa49-bcea-d7564d516a1b May  1 2012,
> StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.158 uuid:
> 82eded98-68af-4c80-a472-4f6de293adcf May  1 2012,
> https://git.gitorious.org/cogvm/blessed.git Commit:
> 6aa3fd0f1188078d3167dec1a53031a61b97b688 Date: Tue May 1 20:28:14 2012
> +0200 By: Esteban Lorenzano 
> Image: Pharo1.4a [Latest update: #14418]
>
> NBFFICallout(Object)>>error:
>        Receiver: a NBFFICallout
>        Arguments and temporary variables:
>                aString:        'function unavailable'
>        Receiver's instance variables:
>                asm:    an AJx86Assembler
>                proxy:  a NBInterpreterProxy
>                options:        a Set(#optCdecl #optAllowByteArraysPtr 
> #optUseStackPointer
> #optReturnP...etc...
>                method:         (AthensCairoSurface 
> class>>#primImage:width:height: "a
> CompiledMethod(4...etc...
>                fnSpec:         a NBFnSpec
>                requestor:      AthensCairoSurface class
>                methodArgs:     an OrderedCollection('aFormat' 'aWidth' 
> 'aHeight')
>                coercionMayFail:        true
>                callInfo:       an AJCdeclCallInfo
>
> [:gen |
> fnAddress := requestor nbGetSymbolAddress: fnSpec functionName module:
> aModuleNameOrHandle.
>        fnAddress
>                ifNil: [self error: 'function unavailable'].
>        self mayCallback
>                ifTrue: [asm push: fnAddress asUImm32;
>                                 mov: NativeBoost callgateFunctionAddress 
> asUImm32 to: EAX;
>                                 call: EAX]
>                ifFalse: [asm mov: fnAddress asUImm32 to: EAX;
>                                 call: EAX]] in 
> NBFFICallout>>generateCall:module:
>        Receiver: a NBFFICallout
>        Arguments and temporary variables:
>                aModuleNameOrHandle:    a NBFFICallout
>                fnAddress:      '/opt/local/lib/libcairo.2.dylib'
>                gen:    #(nil)
>        Receiver's instance variables:
>                asm:    an AJx86Assembler
>                proxy:  a NBInterpreterProxy
>                options:        a Set(#optCdecl #optAllowByteArraysPtr 
> #optUseStackPointer
> #optReturnP...etc...
>                method:         (AthensCairoSurface 
> class>>#primImage:width:height: "a
> CompiledMethod(4...etc...
>                fnSpec:         a NBFnSpec
>                requestor:      AthensCairoSurface class
>                methodArgs:     an OrderedCollection('aFormat' 'aWidth' 
> 'aHeight')
>                coercionMayFail:        true
>                callInfo:       an AJCdeclCallInfo
>
> BlockClosure>>valueWithPossibleArgs:
>        Receiver: [:gen |
> fnAddress := requestor nbGetSymbolAddress: fnSpec functionName module:
> aModuleNam...etc...
>        Arguments and temporary variables:
>                anArray:        an Array(a NBFFICallout a NBInterpreterProxy 
> an AJx86Assembler)
>        Receiver's instance variables:
>                outerContext:   NBFFICallout>>generateCall:module:
>                startpc:        91
>                numArgs:        1
>
> [aFunctionBodyBlock valueWithPossibleArgs: {self. proxy. asm}.
>        (self optEmitCall
>                        or: [self optNoCleanup])
>                ifTrue: [call disableCleanup]] in [:call |
> self optNoAlignment
>                ifTrue: [call alignment: 1].
>        self pushArguments.
>        coercionMayFail
>                ifTrue: [proxy ifFailedJumpTo: self failedLabel].
>        asm
>                decorateWith: 'FFI: performing a call'
>                while: [aFunctionBodyBlock valueWithPossibleArgs

Re: [Pharo-project] Monticello Browser messing up Morphic?

[Fernando Olivero]

I haven't experienced it.

To recover: The trail generally happens when you have to UI process installed.
Terminate the extra one and things will be back to normal. (try with
both, and the current UI process will tell you it cant be killed).

Fernando

On Tue, May 22, 2012 at 12:24 AM, Sean P. DeNigris
 wrote:
> Every time I go to save a package in the latest 2.0, the world gets messed up
> like http://code.google.com/p/pharo/issues/detail?id=5013. It seems to start
> when I click "Save" and the commit message editor comes up. If I drag it
> around, it leaves a trail (the Process Browser shows a "nil" process at the
> UI priority in addition to the UI process). Once I accept the comment, MC
> Browser gets that big red X thing replacing the list on the left.
>
> Is anyone else seeing this?
>
> Sean
>
> --
> View this message in context: 
> http://forum.world.st/Monticello-Browser-messing-up-Morphic-tp4631248.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

Re: [Pharo-project] Browsing long methods

[Fernando Olivero]

yes, you are right, we should improve Morphic, and Gaucho should be
released soon!

Regarding cleaning up PluggableTextMorph, i think a better solution
would be to rewrite it, i've coded NewTextMorph once (a minimal
version). Instead of trying to fix an complicated Morph.

On Mon, May 21, 2012 at 2:50 PM, Stéphane Ducasse
 wrote:
> Yes but if we do not improve the system and gaucho is not usable by other 
> than you
> then at the end we got nothing so the solution is
>        to improve the system
>        and eventually be ready to switch to something better but not before :)
>
> Stef
>
>> PluggableTextMorph and friends  are a mess, i've tried to clean it up
>> once and found it to be really hard.
>>
>> I will be showing the support for text in Shapes ( the UI framework
>> used by Gaucho), which lays  out text using Pango, and renderers it
>> using Athens (with a Cairo backend). Simple and yet powerful, thanks
>> to Pango.
>>
>> Fernando
>>
>>
>> On Mon, May 21, 2012 at 12:42 PM, Guillermo Polito
>>  wrote:
>>> Nice, the paragraph is calculated about 7~8 times in a pluggable text morph 
>>> (depending on the user).
>>>
>>> And since the composition of a paragraph for a long method takes long (some 
>>> minutes), it takes 7 times to render it (I've never was able to wait for 
>>> it.  I always lose my patience before).
>>>
>>> Guille
>>>
>>> On Mon, May 21, 2012 at 11:41 AM, Guillermo Polito 
>>> mailto:guillermopol...@gmail.com>> wrote:
>>> Browsing a long method (lets say, of ~270KB of sourcecode) just hangs the 
>>> image.
>>>
>>> Interrupting doesn't even give me control over my image again.  It does no 
>>> open a debugger, but info is printed in stdout, so I assume that my 
>>> UIProcess died, but the event fetcher is still alive...
>>>
>>> One of the processes that get interrupted prints:
>>>
>>> SmallIdentityDictionary(SmallDictionary)>>at:ifAbsent:
>>> MorphExtension>>valueOfProperty:ifAbsent:
>>> MorphExtension>>valueOfProperty:
>>> ScrollBar(Morph)>>valueOfProperty:
>>> ScrollBar(Morph)>>theme
>>> ScrollBar>>normalThumbFillStyle
>>> ScrollBar>>adoptGradientColor:
>>> ScrollBar>>sliderColor:
>>> ScrollBar>>adoptPaneColor:
>>> PluggableMultiColumnListMorph(Morph)>>adoptPaneColor: in Block: [:m | m 
>>> adoptPaneColor: paneColor]
>>>
>>> So I just changed #adoptPaneColor: in ScrollBar to do nothing, and I am 
>>> able to interrupt again. So it makes me think here it is where the 
>>> UIProcess gets killed...
>>>
>>> Now, for the browser stuff, it seems that TextComposer>>#composeAllLines 
>>> never finishes.  I'm still investigating, but any clue is helpful :).
>>>
>>> Guille
>>>
>>
>

Re: [Pharo-project] Browsing long methods

[Fernando Olivero]

PluggableTextMorph and friends  are a mess, i've tried to clean it up
once and found it to be really hard.

I will be showing the support for text in Shapes ( the UI framework
used by Gaucho), which lays  out text using Pango, and renderers it
using Athens (with a Cairo backend). Simple and yet powerful, thanks
to Pango.

Fernando


On Mon, May 21, 2012 at 12:42 PM, Guillermo Polito
 wrote:
> Nice, the paragraph is calculated about 7~8 times in a pluggable text morph 
> (depending on the user).
>
> And since the composition of a paragraph for a long method takes long (some 
> minutes), it takes 7 times to render it (I've never was able to wait for it.  
> I always lose my patience before).
>
> Guille
>
> On Mon, May 21, 2012 at 11:41 AM, Guillermo Polito 
> mailto:guillermopol...@gmail.com>> wrote:
> Browsing a long method (lets say, of ~270KB of sourcecode) just hangs the 
> image.
>
> Interrupting doesn't even give me control over my image again.  It does no 
> open a debugger, but info is printed in stdout, so I assume that my UIProcess 
> died, but the event fetcher is still alive...
>
> One of the processes that get interrupted prints:
>
> SmallIdentityDictionary(SmallDictionary)>>at:ifAbsent:
> MorphExtension>>valueOfProperty:ifAbsent:
> MorphExtension>>valueOfProperty:
> ScrollBar(Morph)>>valueOfProperty:
> ScrollBar(Morph)>>theme
> ScrollBar>>normalThumbFillStyle
> ScrollBar>>adoptGradientColor:
> ScrollBar>>sliderColor:
> ScrollBar>>adoptPaneColor:
> PluggableMultiColumnListMorph(Morph)>>adoptPaneColor: in Block: [:m | m 
> adoptPaneColor: paneColor]
>
> So I just changed #adoptPaneColor: in ScrollBar to do nothing, and I am able 
> to interrupt again. So it makes me think here it is where the UIProcess gets 
> killed...
>
> Now, for the browser stuff, it seems that TextComposer>>#composeAllLines 
> never finishes.  I'm still investigating, but any clue is helpful :).
>
> Guille
>

Re: [Pharo-project] Pharo is exploding

[Fernando Olivero]

I've recently read the book on UI usability [1], were the author
states that after ten years of performing user evaluations and
studies, he can assert that "people stick to the first thing that
works".

 Maybe that's the reason behind this aversion to change.

I totally agree with Marcus and others, Pharo1.3 is FROZEN.

So why work on the BLEEDING EDGE, if you cant cope with a changing system.


Fernando

[1] Dont make me think, Steve Kruger.

On Wed, May 16, 2012 at 9:49 AM, Marcus Denker  wrote:
>
> On May 16, 2012, at 9:23 AM, Pavel Krivanek wrote:
>
>> On Tue, May 15, 2012 at 11:29 PM, Stéphane Ducasse
>>  wrote:
> It depends. Pharo 2.0 is UNSTABLE. It says it everywhere. If you want to 
> do
> seriuous development you won't beusing Pharo 2.0, will you? ;)

 I talked about that few days ago with Germán. The problem is not in
 using of unstable version. The problem is that it is very easy to stop
 to be in touch with Pharo now and within one year when the current
 unstable version will become stable the developers will face to very
 different system. That is one of the reason why Germán choose Cuis for
 his current projects. Developers want simple predictable system.
>>>
>>> Absolutely wonderful. So what people wants just the same. Ok but this is 
>>> not Pharo.
>>> And and and again again again and again who is concerned by RPackage vs 
>>> PackageInfo,
>>> systemNotifier vs. announcement, better monticello, better canvas, better 
>>> Zinc….
>>> I find that a totally false argument.
>>
>> I will quote Germán (I hope he will not mind): "lot and lot of
>> things... Lot of new things each day.
>
> Part of that is that I started the project "tweet something about Pharo every 
> day".
> some 15 months? ago... my idea was that we need to make public what
> happens because most people's perception was : Smalltak is dead.
>
> If people want I can stop.
>
>> Not time to stabilize nothing.
>
> Pharo 1.4 is frozen. We just fix bugs. The same with 1.3. Or even 1.2...
>
>> Is needed such acceleration? ... My point is, I'm trying to move a
>> business with Smalltalk and the acceleration of Pharo is well know by
>> me (from other companies) and sooner or later, impact in my job and
>> I'm a very LITTLE software house can't migrate my products all the
>> time."
>>
> You should *not* migrate. That's the idea. Just as one uses a (in the future
> unchanging Cuis, I am sorry to hear that), you can use an unchaning Pharo 1.4,
> or 1.3.
> Only when your project needs it, (because you actively with manpower develop 
> it
> for a longer time), you can move to a new version.
>
>> We simply have to accept that some developers can have this feelings
>> and try to find a way how to limit it. I think that some official
>> Pharo blog (maybe written by Esteban) would be very helpful. Some kind
>> of not very extensive technical information source that will help
>> people to stay in touch with Pharo progress. That will explain what is
>> being changed in Pharo and why. I think that developers than will see
>> the changes like positive not as alien ones.
>>
>
> What I think is problematic: Peopler are against Change. But when somone
> nevertheless does it, build a great system, the same people that did not allow
> us to move will gladly abandon the old system for the new system.
> Cuis is a good example. According to the Philosophy of German, it should not 
> exist.
>
> Maybe we should partition the *mailinglist* by stable and unstable?
> This way people using the stable don't see the noise and can focus...
>
>        Marcus
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>

Re: [Pharo-project] [Pharo-consortium] We need your successes

[Fernando Olivero]

I'll prepare one, detailing myself and Gaucho.
Fernando

On Sat, May 12, 2012 at 9:50 PM, Stéphane Ducasse
 wrote:
> Thanks Hilaire for this cool one :)
>
>
>        https://gforge.inria.fr/frs/download.php/30761/drgeo-teaser.pdf
>
> I should do one for http://www.synectique.eu
>
> Stef
>

Re: [Pharo-project] Strange logic in PolygonMorph>>fromHand: hand

[Fernando Olivero]

Indeed is weird. I think it has to explicitly call runStepMethods,
because it's not forking , thus taking control of the ui process, does
it make sense?

I would remove the method (and all the similar ones found in the
image, that explicitly reference Sensor and while doing "true
whileTrue:[ ...]", if needed it would be have to re-done using the new
event model with announcements.

Fernando

On Sun, May 13, 2012 at 10:20 AM, Stéphane Ducasse
 wrote:
> Hi
>
> I'm cleaning Sensor use so that we end up with a better layered system.
> Now I see this method and I wonder (replacing Sensor by hand does not work.
> But I do not understand why this methods has to explicitly invoke 
> runStepMethods… to me it looks like a broken behavior
> due probably to the lack of a functionality or ticking behavior.
>
> What do you think?
>
> fromHand: hand
>        "Let the user draw a polygon, clicking at each vertex, and ending
>                by clicking within 5 of the first point..."
>        "self fromHand: ActiveHand"
>
>        | p1 poly oldVerts pN opposite |
>        Cursor crossHair showWhile:
>                [[Sensor anyButtonPressed] whileFalse:
>                        [self currentWorld displayWorldSafely; runStepMethods].
>                p1 := Sensor cursorPoint].
>        opposite := (Display colorAt: p1) negated.
>        opposite = Color transparent ifTrue: [opposite := Color red].
>        (poly := LineMorph from: p1 to: p1 color: opposite width: 2) 
> openInWorld.
>        oldVerts := {p1}.
>        self currentWorld displayWorldSafely; runStepMethods.
>        [true] whileTrue:
>                [[Sensor anyButtonPressed] whileTrue:
>                        [pN := Sensor cursorPoint.
>                        poly setVertices: (oldVerts copyWith: pN).
>                        self currentWorld displayWorldSafely; runStepMethods].
>                (oldVerts size > 1 and: [(pN dist: p1) < 5]) ifTrue:
>                        [hand position: Sensor cursorPoint.  "Done -- update 
> hand pos"
>                        ^ (poly setVertices: (poly vertices copyWith: p1)) 
> delete].
>                oldVerts := poly vertices.
>                [Sensor anyButtonPressed] whileFalse:
>                        [pN := Sensor cursorPoint.
>                        poly setVertices: (oldVerts copyWith: pN).
>                        self currentWorld displayWorldSafely; runStepMethods]].
>
>

Re: [Pharo-project] Short rant on platforms and sessions

[Fernando Olivero]

That's why the OpenGL examples work when you re-open a saved image!

Fernando

On Fri, May 11, 2012 at 12:51 PM, Igor Stasenko  wrote:
> I agree with all your points.
> I just can add, that if you start using NativeBoost FFI you'll find
> that it follows _exactly_ the rules which you listed.
> i dont know much about dolphin, but session awareness is one of the
> first things which i implemented in NB, because as to me, it is the
> right way how things should be done.
>
>
> On 11 May 2012 04:08, Schwab,Wilhelm K  wrote:
>> It's a nice system - we should take lessons from it where we can.  In this 
>> case, they *clearly* have it right.
>>
>>
>>
>>
>> 
>> From: pharo-project-boun...@lists.gforge.inria.fr 
>> [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Chris Muller 
>> [asquea...@gmail.com]
>> Sent: Thursday, May 10, 2012 8:56 PM
>> To: Pharo-project@lists.gforge.inria.fr
>> Subject: Re: [Pharo-project] Short rant on platforms and sessions
>>
>>> Dolphin shows us the correct path: session awareness.  The image "wakes up"
>>> and decides where it is running - the vm can certainly help in Pharo's
>>> case.  External resources are *not* cleared on image save - the image might
>>> keep running, so why release and reallocate?  Finalization is best-effort.
>>> External resources are cleared just before exiting, but *after* any
>>> associated image save.  When the image wakes, one of its first duties is to
>>> clear (not release via calls) any external resources, because they are known
>>> to be garbage at this point.
>>>
>>> It works, and works well.
>>
>> I don't have experience with Dolphin, but that does sound like a
>> clever solution to avoiding the release/reallocate burden on image
>> save (and not exiting)..
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-project] [review needed] Do we remove SmartRefStream?

[Fernando Olivero]

I would remove them, you made a strong point in favor of simply
removing it: A cleanup of an unneeded class.

Its nice to see this kind of complex classes disappear from Pharo,
more and more.

Fernando

On Fri, May 11, 2012 at 10:27 AM, Marcus Denker  wrote:
>
> With Fuel, we should take the opportunity to clean up the systm. There are 
> things we need to keep
> for a while (DataStream, for example, a it is used by Monticello).
>
> But what about SmartRefStream? With ImageSegment already gone, does it make 
> sense to keep
> it? The code looks horrible.
>
> One can just remove it and all remaining users like this:
>
> http://code.google.com/p/pharo/issues/detail?id=5859
>
> Can we do that? do we need to formally deprecate it?
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>

Re: [Pharo-project] Anti-aliased rendering status?

[Fernando Olivero]

Yes! Browse in the mailing list for the work on Athens[1], a new
canvas rendering API, that supports different backends (currently
Cairo [2]).

 Check out this video: http://vimeo.com/40653315.

Morphs can easily use this new canvas by implementing
drawOnAthensCanvas: (as oposed to #drawOn:).

I am developing a new UI interface, rebuilt from the ground up to take
advantage of Athens, named Gaucho: a zoomable user interface IDE. But
its still not ready for release, (very soon it will be announced ).

For more info and examples, browse this mailing list and check for
Athens, SVG, Gaucho.

All the  examples you mention,are done by hand, playing with the
border fill styles i suppose.
And the fonts, are FreeType fonts.



Saludos,
Fernando

[1]http://www.squeaksource.com/Athens
[2]http://www.cairographics.org/

On Sun, Apr 29, 2012 at 9:58 AM, Martin Drautzburg
 wrote:
> Hello all
>
> I noticed, that fonts are rendered anti-aliased, but a CircleMorph look
> pixelized. Then the Buttons in the Watery2 theme look anti-aliased, at least
> to me. How was that achieved?
>
> I also stumbeled across Morphic3, but it seems to be primarily a sound theory
> for anti-aliased rendering, rather than usable software, right?
>
> Anyways: is there currently some way to get rid of pixelized Morphs?
>
> --
> Martin
>

Re: [Pharo-project] Athens & SVG (was: Re: new icon set )

[Fernando Olivero]

Thanks! I wasnt aware of that projec.
Fernando

On Thu, Apr 26, 2012 at 4:36 AM, Sean P. DeNigris  wrote:
>
> Fernando olivero-2 wrote
>>
>> Seems it depends on XMLDOMParser?
>> How can i install it?
>>
>
>        Gofer new
>        squeaksource:  'MetacelloRepository';
>        package:  'ConfigurationOfXMLSupport'; load.
>
>        (Smalltalk at: #ConfigurationOfXMLSupport) load.
>
> Sean
>
> --
> View this message in context: 
> http://forum.world.st/Athens-SVG-was-Re-new-icon-set-tp4585623p4588733.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

Re: [Pharo-project] Athens & SVG (was: Re: new icon set )

[Fernando Olivero]

Seems it depends on XMLDOMParser?
How can i install it?



On Thu, Apr 26, 2012 at 3:30 AM, Fernando Olivero
 wrote:
> NICE!!! Great work Igor!
>
> Fernando
>
> On Wed, Apr 25, 2012 at 7:59 AM, Igor Stasenko  wrote:
>> .. and , of course, some screenshots for thirsty people ;)

Re: [Pharo-project] Athens & SVG (was: Re: new icon set )

[Fernando Olivero]

NICE!!! Great work Igor!

Fernando

On Wed, Apr 25, 2012 at 7:59 AM, Igor Stasenko  wrote:
> .. and , of course, some screenshots for thirsty people ;)

Re: [Pharo-project] [update 2.0] #20009

[Fernando Olivero]

great! We should say our farewells to BlockContext and
SourceReference, amongst others...

On Tue, Apr 24, 2012 at 6:20 PM, Marcus Denker  wrote:
> 20009
> -
>
> Issue 5564:     Support bit operations on Boolean / Integers
>        http://code.google.com/p/pharo/issues/detail?id=5564
>
> Issue 5641:     Unload Deprecated14
>        http://code.google.com/p/pharo/issues/detail?id=5641
>
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>

Re: [Pharo-project] Pharo and the rest of the ecosystem

[Fernando Olivero]

That's a good point. I regularly see that Stef and others harvest
enhancements and fixes from Squeak and CUIS. Surely, the other way
around is also true.

We simply have to live with the fact that many forks exist, and each
of them is maintained by a small set of people who put a lot of energy
into their own system.
And sometimes they will collaborate, and sometimes not.

The community behind Pharo, shouldnt be required to always be aware of
external enhancements. And vice-versa for the remaining forks.

Fernando

On Tue, Apr 24, 2012 at 12:38 PM, Stéphane Ducasse
 wrote:
>>> Now I do not see the points related to spoon and cuis. I do not understand 
>>> what is the point.
>>> If people wants to collaborate with us this is ok now we do not count on 
>>> that for our future.
>>>
>>> You do not have to reply. Just think about what you want to build and your 
>>> future. Everybody
>>> make choices and is free.
>>
>> I see the point behind Cuis/Spoon discussion in a wish to avoid
>> duplication efforts in Smalltalk community. A wish to hear from you a
>> word, something like: "yes we will look in Cuis to see if we can reuse
>> some ideas or even code". To express just a will to look at achievements
>> of others would help here. I think this is what many of us wants to hear.
>
> Did you notice that we ***already*** harvested some of the CUIS items?
> Now it does not make sense to stay compatible for the sake of it.
> Look CUIS changes the class definition meta data and this is ok. Now nobody 
> went to say
> to Juan that he should not … blablbalbalba
>
> Stef
>
>> Best regards
>> Janko
>>
>>
>>
>> --
>> Janko Mivšek
>> Aida/Web
>> Smalltalk Web Application Server
>> http://www.aidaweb.si
>>
>
>

Re: [Pharo-project] new icon set

[Fernando Olivero]

oh! you just solved an issue i've had with the icons in the Gaucho ZUI.

Scaling .png icons results in a great lost of quality, so  i was
creating my own icons by hand using Athensbut i'm not a
profesional designer, so... now i can plug a IconFamilySet that
renders svg icons via Athens!

Does the current SVG importer reads such icon files? or i have to wait
a bit more.

Fernando

On Tue, Apr 24, 2012 at 1:36 AM, Igor Stasenko  wrote:
> no, guys.. you lost me.. the things you propose is like stone age :)
>
> i want something which will give us much better things..
> like this one:
> http://raphaeljs.com/icons/
> or this:
> http://www.tehkseven.net/blog/1/entry-1066-475-free-awesome-high-quality-icons-for-designers/
>
> and they are in SVG format.. so you don't lose a bit of quality ..
> never. anymore :)
>
> On 24 April 2012 01:44, Martin Sandiford  wrote:
>> How about "cake" from the silk set? :)
>>
>> More seriously, what about "rosette"?
>>
>> I'm guessing that this is the set used:
>> http://www.famfamfam.com/lab/icons/silk/previews/index_abc.png
>>
>> The bullets look kind of familiar from OmniBrowser test cases.
>>
>> Cheers,
>> Martin
>>
>> On Mon, Apr 23, 2012 at 11:02 PM, Guillermo Polito
>>  wrote:
>>> I like them.  Except for the test runner one :P.  Isn't there any other
>>> nicer?
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-project] The video about Athens

[Fernando Olivero]

Great work Igor!  One more step towards nicer looking apps developed
in Pharo in the near future

What features are missing from a full-blown SVG spec? Gradients?

Fernando

On Mon, Apr 23, 2012 at 5:23 PM, Guillermo Polito
 wrote:
> Nice simba :).
>
> On Mon, Apr 23, 2012 at 5:20 PM, Igor Stasenko 
> mailto:siguc...@gmail.com>> wrote:
> Some progress with SVG importer..
>
> Don't be too optimistic, this is pretty simple svg document, which
> uses only colors and polygons..
> it will require a more work to implement full SVG spec , but i just
> wanna share first results :)
>
> See that guy here in your browser:
> http://croczilla.com/bits_and_pieces/svg/samples/lion/lion.svg
>
>
> --
> Best regards,
> Igor Stasenko.
>