Re: [Pharo-dev] Difficulty to use Iceberg

[Jan Vrany]

On 2019-09-23 23:25, Sean P. DeNigris wrote:
> Jan Vrany wrote
>> What is the correct workflow to end up with:
>> --- A --- B --- C --- D --- E
> 
> Not in front of an image, but IIU/RC if you’re seeing “detached”, click
> repair, then the option where you use the repository version (which I think
> I the last one), then - if the outside changes didn’t effect the Smalltalk
> code - from the drop down choose “don’t check anything out” which is
> confusing but means that it won’t try to reload any packages in Pharo.  The
> result of those steps should be that Pharo recognizes the latest commit. Let
> me know whether it works and I’ll be more exact when I get in front of a
> computer

Thanks! Unfortunately, this discards any changes in working copy. 
i.e., any files `git status` reports a "modified". Without any 
warning. 

Cheers,
Jan


> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Difficulty to use Iceberg

[Jan Vrany]

Hi Tim, 

thanks! Yes, there are other ways to get around this,
but all i tried are major PITAs. Was wondering there
must be a better way...

Thanks anyway! Jan

> Hi Jan - if I’ve understood you correctly, I think this is the same
> issue you would get with a readme.md file in the root of your project,
> as iceberg only deals with its repository tree and nothing else (which
> has been queried in the past - but it’s a design decision for now, 
> we’ve been told).
> 
> To workaround this, checkout your project into a separate directory
> for the C part, and pull push independently from pull push in Pharo
> part (eg, just pretend you are different users collaborating on the
> same project). It works, but remember to do the pull - to catchup when
> you have done something in the other world.
> 
> Tim
> 
> Sent from my iPhone
> 
>> On 22 Sep 2019, at 09:15, Jan Vrany  wrote:
>>
>> Hi,
>>
>> I'm experiencing difficulties (code loss, even) when trying to
>> commit code using Iceberg.
>>
>> I have a project with consist of some Pharo code and some
>> C++ code. Both parts kind of depend on each other.
>>
>> Imagine I start from commit A
>>
>> --- A
>>
>> and build and open Pharo image. Then I do some work in
>> Pharo and commit, leaving me at B:
>>
>> --- A --- B
>>
>> Now I need to make some changes to the C++ code, say C & D:
>>
>> --- A --- B --- C --- D
>>
>> And work little more on C++ but do not commit (therefore I have
>> modified C++ files and/or staged changes). Now imagine I need to
>> do more changes in Pharo image and commit (should be commit E)
>>
>> Now there's the problem. Pharo image thinks it is still at commit B
>> and starts complaining about image being out if sync.
>>
>> What is the correct workflow to end up with:
>>
>> --- A --- B --- C --- D --- E
>>
>> !!! AND !!! with my local modifications to C++ code preserved
>> in working copy? I'd be nice to preserve staged changes too,
>> but I'd be OK to unstage all changes if necessary.
>>
>> Any suggestions?
>>
>> Best, Jan
>>
>>

[Pharo-dev] Difficulty to use Iceberg

[Jan Vrany]

Hi, 

I'm experiencing difficulties (code loss, even) when trying to 
commit code using Iceberg. 

I have a project with consist of some Pharo code and some
C++ code. Both parts kind of depend on each other. 

Imagine I start from commit A

--- A

and build and open Pharo image. Then I do some work in
Pharo and commit, leaving me at B:

--- A --- B

Now I need to make some changes to the C++ code, say C & D:

--- A --- B --- C --- D

And work little more on C++ but do not commit (therefore I have
modified C++ files and/or staged changes). Now imagine I need to
do more changes in Pharo image and commit (should be commit E)

Now there's the problem. Pharo image thinks it is still at commit B
and starts complaining about image being out if sync. 

What is the correct workflow to end up with:

--- A --- B --- C --- D --- E

!!! AND !!! with my local modifications to C++ code preserved
in working copy? I'd be nice to preserve staged changes too,
but I'd be OK to unstage all changes if necessary.

Any suggestions? 

Best, Jan

Re: [Pharo-dev] About method comments

[Jan Vrany]

Hi Esteban,

On Fri, 2018-02-09 at 15:17 -0300, Esteban A. Maringolo wrote:
> 
> And rename refactorings usually don't rename the comments
> (hopefully).
> 
Why hopefully? Java IDEs rename references to the method also
in comments, I found it very nice. Why it should not? I'm just curious.

Best, Jan

Re: [Pharo-dev] Layout for placing widgets

[Jan Vrany]

On Sat, 2017-10-28 at 10:48 +0200, Stephane Ducasse wrote:
> Pavel I do not think that cassowary is good for us.

Why?

Jan

> 
> 
> On Sat, Oct 28, 2017 at 2:37 AM, Todd Blanchard 
> wrote:
> > Does that load as part of Bloc?
> > 
> > On Oct 27, 2017, at 12:59 PM, Pavel Krivanek  > com>
> > wrote:
> > 
> > Maybe we should check cassowary
> > 
> > https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/#
> > ui-constraints
> > 
> > 2017-10-27 19:13 GMT+02:00 Stephane Ducasse  > m>:
> > > 
> > > Hi
> > > 
> > > I was wondering if there is a layout that we can use to propose
> > > alternate placing layout
> > > for widgets in spec?
> > > 
> > > Like
> > > 
> > > attached to  the left 10pixels rubber band box or fixed size box
> > > 10pixels attached to the right.
> > > 
> > > 
> > > Stef
> > > 
> > 
> > 
> 
> 

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

[Jan Vrany]

Hi, 

> I was thinking of changing that, adding a primitive which answers a
> CogMethod as a bytearray, but you still need to use external libs
> such as gdb/lldb to disassemble your binary 

I use udis86 [1] for that purpose. Tiny, clean & dead easy to use. 
x86 only, though. 

HTH. Jan

[1]: http://udis86.sourceforge.net/


> (which is possible but not working out of the box everywhere and it
> does not make sense to include that as part of the VM), and you still
> need something extracted from VMMaker to make sense out of the
> CogMethod header and CogMethod map, which has a lot of dependencies,
> so likely the whole VMMaker itself. And I'm not talking about all the
> different CogMethod flavors.
> 
> With VMMaker loaded you can do it with in-image compilation but you
> will have the machine code with only unlinked sends. With linked send
> it's more difficult as you need to really simulate the whole runtime.
> 
> Overall there's no amazing solution. In the example shown it's easier
> as in C++ the code is not modified while it runs and you've already
> have gdb/lldb APIs to show what they show.
> 
>  
> > 
> > 
> >  
> > > 
> > > 
> > > Cheers,
> > > Doru
> > > 
> > > 
> > > > On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo  > > > gmail.com> wrote:
> > > > 
> > > > I'm sure we could do this with ease, because we already can see
> > > > the bytecodes.
> > > > 
> > > > https://godbolt.org/
> > > > 
> > > > Regards!
> > > > 
> > > > Esteban A. Maringolo
> > > > 
> > > 
> > > --
> > > www.tudorgirba.com
> > > www.feenk.com
> > > 
> > > "The coherence of a trip is given by the clearness of the goal."
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > -- 
> > Mariano
> > http://marianopeck.wordpress.com
> > 
> 
> 
> 
> -- 
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Reproducible VM Crash using UFFI

[Jan Vrany]

> So I think we are talking about different things here. I don't want
> to
> save "bad memory block" errors nor dream about bullet proof VM, but
> if
> we know the bullet then let's use a nice bulletproof vest :)
> 

This can be done and has been done. 

Following code would clearly result in segmentation violation: 

bytes := ExternalBytes address: 16r10 size: 100.
bytes byteAt: 1 put: 10.

There are smalltalk implementations out there that handle
this and open a (smalltalk) debugger (see the screenshot). 
Of course, you can just abort, fix your code and 
try again. 

Of course, if you happen to overwrite your object memory
or VM internal structures, you're screwed. 

As you said, you can still be shot and die, but the west can 
save your life in some cases :-)

Best, Jan

Re: [Pharo-dev] About cr and lf

[Jan Vrany]

On Fri, 2017-08-04 at 14:06 +0200, Stephane Ducasse wrote:
> Well. This is not implemented like that in Pharo.
> 
> cr is bad because it does not mean that it is independent of the
> platform.
> So cr can be redefined as newLine and keep but not used inside the
> system.

Yes, that's exactly what I meant.

cr 
   self newLine

Jan
> 
> Stef
> 
> On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany 
> wrote:
> > On Fri, 2017-08-04 at 12:03 +0200, Stephane Ducasse wrote:
> > > Hi guys
> > > 
> > > While writing pillar code, I ended up using "stream cr" and it
> > > worries
> > > me to still expand usage
> > > of a pattern I would like to remove.
> > > 
> > > Let us imagine that we would like to prepare the migration from
> > > cr.
> > > I was thinking that we could replace cr invocation by newLine so
> > > that
> > > after newLine
> > > could be redefined as
> > > 
> > > Stream >> newLine
> > >    self nextPutAll: OSPlatform current lineEnding
> > > 
> > > 
> > > what do you think about this approach?
> > 
> > Why not? But please keep #cr.
> > 
> > Section 5.9.4.1 of ANSI reads:
> > 
> > Message: cr
> > 
> > Synopsis
> >  Writes an end-of-line sequence to the receiver.
> > 
> > Definition: 
> >  A sequence of character objects that constitute the
> > implementation-
> >  defined end-of-line sequence is added to the receiver in the same
> >  manner as if the message  #nextPutAll: was sent to the receiver
> > with
> >  an argument string whose elements are the sequence of characters.
> > 
> > Return Value
> >  UNSPECIFIED
> > Errors
> >  It is erroneous if any element of the end-of-line sequence is an
> >  object that does not conform to the receiver's sequence value type
> > .
> > 
> > my 2c,
> > 
> > Jan
> > 
> > > 
> > > Stef
> > > 
> 
> 

Re: [Pharo-dev] About cr and lf

[Jan Vrany]

On Fri, 2017-08-04 at 12:03 +0200, Stephane Ducasse wrote:
> Hi guys
> 
> While writing pillar code, I ended up using "stream cr" and it
> worries
> me to still expand usage
> of a pattern I would like to remove.
> 
> Let us imagine that we would like to prepare the migration from cr.
> I was thinking that we could replace cr invocation by newLine so that
> after newLine
> could be redefined as
> 
> Stream >> newLine
>    self nextPutAll: OSPlatform current lineEnding
> 
> 
> what do you think about this approach?

Why not? But please keep #cr. 

Section 5.9.4.1 of ANSI reads: 

Message: cr

Synopsis
 Writes an end-of-line sequence to the receiver.

Definition: 
 A sequence of character objects that constitute the implementation-
 defined end-of-line sequence is added to the receiver in the same 
 manner as if the message  #nextPutAll: was sent to the receiver with
 an argument string whose elements are the sequence of characters.

Return Value
 UNSPECIFIED
Errors
 It is erroneous if any element of the end-of-line sequence is an
 object that does not conform to the receiver's sequence value type . 

my 2c,

Jan

> 
> Stef
> 

Re: [Pharo-dev] FileTree/Iceberg and SSDs, change the file format

[Jan Vrany]

On Wed, 2017-05-24 at 11:46 +0530, K K Subbu wrote:
> On Tuesday 23 May 2017 08:37 PM, Jan Vrany wrote:
> > Hi,
> > 
> > > > Is it possible to build a file responder right into Pharo and
> > > > expose packages through WebDAV or FUSE or sshfs service? Then
> > > > the
> > > > contents can go directly from RAM (pharo) to RAM (repo server
> > > > or
> > > > git) without going through slow disk filesystem.
> > > 
> > > Yes it's possible and really interesting for lots of
> > > reasons.  Not
> > > sure why no one is exploring this avenue.
> > 
> > I did explored this path with FUSE ages age (~10 yeas, IIRC) and,
> > if my memory is not failing me, was possible but turned out to be
> > useless in practice. The problem was that the call to fuse entered
> > a kernel and sit there until there was a FS request at which point
> > it called back my smalltalk. This means smalltalk was unresponsive
> > most of the time. Besides, one needed superuser priviledges and all
> > that stuff. Things may be different these days.
> 
> Yes, FUSE has evolved. Here is a recent paper on it:

It did, indeed. Thanks! 

I had a wee look at the newest source and it looks
one would still have to implement fuse event loop [1] herself. 
It seems that functions needed are not part of public fuse API so
one may need to enter a thin ice of using internal API which may 
not be visible from outside. 

Still, seems doable.

Jan


[1]: https://github.com/libfuse/libfuse/blob/master/lib/fuse_loop.c#L19

Re: [Pharo-dev] FileTree/Iceberg and SSDs, change the file format

[Jan Vrany]

Hi, 

> > Is it possible to build a file responder right into Pharo and
> > expose packages through WebDAV or FUSE or sshfs service? Then the
> > contents can go directly from RAM (pharo) to RAM (repo server or
> > git) without going through slow disk filesystem.
> 
> Yes it's possible and really interesting for lots of reasons.  Not
> sure why no one is exploring this avenue.

I did explored this path with FUSE ages age (~10 yeas, IIRC) and, 
if my memory is not failing me, was possible but turned out to be
useless in practice. The problem was that the call to fuse entered
a kernel and sit there until there was a FS request at which point
it called back my smalltalk. This means smalltalk was unresponsive
most of the time. Besides, one needed superuser priviledges and all
that stuff. Things may be different these days.

Some another 10 years before me Claus did exactly the same thing
using NFSv3, being able to "mount" running Smalltalk image. Last time
I tried it still worked. I was never used for anything practical,
as far as I can recall. 


Jan

> > 
> > Regards .. Subbu
> > 
> 
> 

Re: [Pharo-dev] subexpression precedence

[Jan Vrany]

On Wed, 2017-01-11 at 21:38 -0800, Martin McClure wrote:
> On 01/11/2017 04:54 PM, Jan Vrany wrote:
> > Hi, I'm afraid this is not specified. There's no
> > language specification (*) as such of Pharo or any
> > other available smalltalk - at least not that I know
> > (prove me if I'm wrong).
> 
> The ANSI Smalltalk spec says
> 
> "The individual statements are executed in left to right sequence,"
> but 
> in context I believe that this just means that you execute the first 
> statement in the method, then the next, and so on.
> 
> Ah, here it is. Section 3.4.5.3 says
> 
> "The receiver and the arguments are evaluated before the message is 
> sent. They are evaluated in a left-to-right order."
> So that's pretty clear.

Oops, I overlooked this. Thanks! 

Jan
> 
> Regards,
> 
> -Martin
> 
> 

Re: [Pharo-dev] subexpression precedence

[Jan Vrany]

Hi, I'm afraid this is not specified. There's no
language specification (*) as such of Pharo or any 
other available smalltalk - at least not that I know 
(prove me if I'm wrong). 

Order in which subexpressions are evaluated is rarely specified.
IIRC, JVM Spec doesn't specify it either. 

If the question was rather "How does it work in current Pharo 
implementation?", then it's easy to check, just add some sideffects 
to subexpressions (like Transcript show) and see in what order 
they're executed :-) 

(*) Specification in a sense of Java Language Spec, 
C# Language Specification, C99 Spec and so on. 

Jan

On Wed, 2017-01-11 at 16:16 -0800, James Ladd wrote:
> Hi Pharo People,
> 
> I know Smalltalk has precedence rules when subexpressions () are
> involved.
> 
> 2 + (  (3 * 4) - 1  )
> evaluated last (   (evaluated first)  evaluated second  )
> 
> That is the inner most subexpression is evaluated first.
> 
> Given the following made up expression for the purposes of my
> question:
> 
> self at: (self offset) - 1 put: (2 * (12 / 4)).
> 
> Are there precedence rules for the subexpressions that are part of
> the
> keyword expression?
> ie: Should (self offset) - 1 be evaluated before (2 * (12 / 4)).
> 
> My thinking is that with keywords the arguments are evaluated left to
> right
> - that is 
> at: before put: but within each the regular subexpression precedence
> applies?
> 
> - James.
> 
> 
> 
> 
> 
> 
> --
> View this message in context: http://forum.world.st/subexpression-pre
> cedence-tp4929398.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
> 

Re: [Pharo-dev] genJumpLong: distance index 1043 is out of range -1024 to 1023

[Jan Vrany]

On Wed, 2016-12-07 at 11:10 -0800, Eliot Miranda wrote:
> 
> 
> On Wed, Dec 7, 2016 at 9:52 AM, Marcus Denker  > wrote:
> > Hello,
> > 
> > The current bytecode limited the size of jumps.
> > 
> > This means that you will get this error if your mehthods are so
> > complex that they
> > require a jump too large.
> > 
> > Solution: refactor to simplify.
> > 
> > We should improve the error message to explain that.
> > 
> > (this will not happen anymore when the new bytecode set gets
> > adopted).
> > 
> 
> Forgive me being pedantic, but it will simply be much less likely. 
> The limit is raised to +/- 32k bytes, but one can still construct
> methods that will hit these limits.

What prevents you to generate what - if I remember correctly - 
was called jump island? i.e, generate jump to another jump. 
This was/is used a lot on PA-RISCs (I might we wrong, I have
not seen an alive PA-RISC machine for ages now)

Jan

> 
> > > On 7 Dec 2016, at 12:14, Davide Varvello via Pharo-dev  > > @lists.pharo.org> wrote:
> > > 
> > > 
> > > From: Davide Varvello 
> > > Subject: genJumpLong: distance index 1043 is out of range -1024
> > > to 1023
> > > Date: 7 December 2016 at 12:14:35 GMT-3
> > > To: pharo-dev@lists.pharo.org
> > > 
> > > 
> > > Hi,
> > > 
> > > Sometimes (and also today) after formatting and saving a method,
> > > an Error is
> > > thrown.
> > > Following a chunk of PharoDebug.log
> > > 
> > > TIA
> > > Davide
> > > 
> > > 
> > > -
> > > THERE_BE_DRAGONS_HERE
> > > Error: genJumpLong: distance index 1043 is out of range -1024 to
> > > 1023
> > > 7 December 2016 4:21:53.0426 pm
> > > 
> > > VM: Mac OS - intel - 1096 - CoInterpreter
> > > VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid:
> > > 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016
> > > StackToRegisterMappingCogit VMMaker.oscog-
> > > HolgerHansPeterFreyther.1880 uuid:
> > > 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016
> > > https://github.com/pharo-project/pharo-vm.git Commit:
> > > 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30
> > > 08:40:43 +0200 By:
> > > GitHub  Jenkins build #603
> > > 
> > > Image: Pharo5.0 [Latest update: #50763]
> > > 
> > > OpalEncoderForV3PlusClosures(Object)>>error:
> > >   Receiver: an OpalEncoderForV3PlusClosures
> > >   Arguments and temporary variables: 
> > >   aString:    'genJumpLong: distance index 1043 is
> > > out of range -1024 to 1023'
> > >   Receiver's instance variables: 
> > >   stream: an IRBytecodeGenerator
> > >   position:   nil
> > >   rootNode:   nil
> > >   blockExtentsToLocals:   nil
> > > 
> > > 
> > > OpalEncoderForV3PlusClosures(OpalBytecodeEncoder)>>outOfRangeErro
> > > r:index:range:to:
> > >   Receiver: an OpalEncoderForV3PlusClosures
> > >   Arguments and temporary variables: 
> > >   string: 'distance'
> > >   index:  1043
> > >   rangeStart: -1024
> > >   rangeEnd:   1023
> > >   Receiver's instance variables: 
> > >   stream: an IRBytecodeGenerator
> > >   position:   nil
> > >   rootNode:   nil
> > >   blockExtentsToLocals:   nil
> > > 
> > > 
> > > OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJumpLong:
> > >   Receiver: an OpalEncoderForV3PlusClosures
> > >   Arguments and temporary variables: 
> > >   distance:   1043
> > >   Receiver's instance variables: 
> > >   stream: an IRBytecodeGenerator
> > >   position:   nil
> > >   rootNode:   nil
> > >   blockExtentsToLocals:   nil
> > > 
> > > 
> > > OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJump:
> > >   Receiver: an OpalEncoderForV3PlusClosures
> > >   Arguments and temporary variables: 
> > >   distance:   1043
> > >   Receiver's instance variables: 
> > >   stream: an IRBytecodeGenerator
> > >   position:   nil
> > >   rootNode:   nil
> > >   blockExtentsToLocals:   nil
> > > 
> > > 
> > > 
> > > --
> > > View this message in context: http://forum.world.st/genJumpLong-d
> > > istance-index-1043-is-out-of-range-1024-to-1023-tp4926103.html
> > > Sent from the Pharo Smalltalk Developers mailing list archive at
> > > Nabble.com.
> > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

Re: [Pharo-dev] [ANN] FFI Tutorial, Pharo5 / Libclang

[Jan Vrany]

Hi,

I'm quite interested in this, though not in UFFI bit, rather
in bindings as such. 

What is the goal of the project? 

Thanks! 

Best, Jan



On Sun, 2016-09-25 at 01:25 +0800, Ben Coman wrote:
> hi all,
> 
> Just announcing that I'm writing a series of posts on using FFI in
> Pharo 5 to interface to libclang, the interface library for the LLVM
> C
> compiler.
> 
> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-1-preambl
> e/
> 
> I'm writing this from the perspective of a FFI newbie progressively
> learning the system.  I've left in a few mis-steps since I think it
> can be useful seeing what didn't work.
> 
> cheers -ben
> 

Re: [Pharo-dev] tricks for XML parsing.

[Jan Vrany]

On Thu, 2016-07-14 at 11:11 +0200, monty wrote:
> 
> > Sent: Thursday, July 14, 2016 at 2:50 AM
> > From: "Jan Vrany" 
> > To: pharo-dev@lists.pharo.org
> > Subject: Re: [Pharo-dev] tricks for XML parsing.
> > 
> > On Thu, 2016-07-14 at 01:58 +0200, monty wrote:
> > > Thanks for the link.
> > > 
> > > In-place parsing is a non-starter because it means storing the
> > > entire
> > > input as a string in memory, so you could only parse files that
> > > fit
> > > in Pharo's address space. The multi-gigabyte OpenStreetMap docs
> > > the
> > > article mentions would be unparsable with SAX in a 32-bit VM.
> > 
> > I do not understand. I only know expat which does - AFAIK - in-
> > place
> > parsing and surelt does not need the whole input in memory. 
> 
> From the article, footnote 3: "This creates a lifetime dependency–the
> entire source buffer must outlive all document nodes for the
> technique to work"

Ah, I see. I assumed that the consumer would copy data if it needs to
retain them...then the parser can do in-place tricks. 
Perhaps the difference is that I do not consider creation of a DOM
being part of "parsing" (I'm not saying it's not, just that this is a
way I think of the problem which may cause confusion :-) 

> 
> > > There is always the option of an FFI-based parser, but it
> > > shouldn't
> > > be a hybrid like Python's minidom (FFI Expat with a Python DOM
> > > implementation), 
> > > because something like that already exists in Smalltalk/X (FFI
> > > Expat
> > > with a Smalltalk DOM) 
> > 
> > I guess you refer to the implementation I did ages ago. 
> > 
> > > and it was slower than a St/X port of XMLParser in my tests (I
> > > assume
> > > due to the FFI overhead), so it's probably not worth it. 
> > 
> > Very, very interesting. Where can I find the benchmarks? 
> 
> This was well over a year ago, and it was DOM parsing. I was testing
> if St/X (your branch, I think) could be supported by XMLParser in
> addition to Pharo, Squeak, and GS, but I ran into too many
> incompatibilities, like Monticello not working (had to load in .st
> files), #new not sending #initialize, not being able to modify the
> value of a dictionary association directly, #lf/#cr weirdness, so I
> gave up. But not before hacking it enough to kind-of run and compared
> it with the other parsers.

Fair enough. If you want to discuss these problems,  I'd be happy to
help.

> 
> > I just run a very simple benchmark on 112MB document (http://www.xm
> > l-be
> > nchmark.org/downloads.html) and results are quite the opposite: 
> > 
> > Benchmark resut:
> > Generated at :14-07-2016 07:32:25 AM
> > 
> >    Benchmark  Execution Time [ms]  # of M&S GCs
> > [1]  # of newspace GCs [1]   Parameters
> > BenchmarkXML
> > SAX -
> > VW93418 0  
> > 
> >  2060   
> >   SAX -
> > XMLSuite 9921 0
> > 
> > 410   
> > 
> > As you can see, the latter is roughly 10 times faster. 
> 
> That's the VW parser, which is slower than XMLParser. And again, it
> was of DOM parsing.

I see. I got confused since VW's parser class is XMLParser...

> 
> > I agree my implementation which uses Expat is clearly suboptimal 
> > and need to be improved (for example it does not use a ILC-based 
> > send to driver so you have a lot of cache misses and does a lot 
> > of unnecessary memcpy()s, but this can be easily improved)
> 
> Your implementation was fine, and particularly, its XPath/Query was
> very impressive. I wasn't attacking you. 

No worry, I know you were not! Just that I was surprised since my
observations - performance wise - were very different. Now I see we
were talking about different things. 

> My point was just the hybrid approach built on Expat (which is a non-
> validating parser, BTW) should be avoided, in case anyone is
> considering it, based on my experience with minidom vs lxml.etree in
> Python and with St/X's v2 parser. A parser based on LibXLM2, Xerces,
> or something else for SAX, DOM, XPath, etc is probably a better way
> of creating an alternative to pure-Smalltalk parsers.

I tend to disagree, but I think we have different points of view,
that;s why. I have to admit I have not much experience (and need) 
with XML. 
Anyways, I'd like to discuss this more to understand the details.
Perhaps privately as it's not strictly Pharo-development related.


Best, Jan
> 

Re: [Pharo-dev] tricks for XML parsing.

[Jan Vrany]

On Thu, 2016-07-14 at 01:58 +0200, monty wrote:
> Thanks for the link.
> 
> In-place parsing is a non-starter because it means storing the entire
> input as a string in memory, so you could only parse files that fit
> in Pharo's address space. The multi-gigabyte OpenStreetMap docs the
> article mentions would be unparsable with SAX in a 32-bit VM.

I do not understand. I only know expat which does - AFAIK - in-place
parsing and surelt does not need the whole input in memory. 

> There is always the option of an FFI-based parser, but it shouldn't
> be a hybrid like Python's minidom (FFI Expat with a Python DOM
> implementation), 
> because something like that already exists in Smalltalk/X (FFI Expat
> with a Smalltalk DOM) 

I guess you refer to the implementation I did ages ago. 

> and it was slower than a St/X port of XMLParser in my tests (I assume
> due to the FFI overhead), so it's probably not worth it. 

Very, very interesting. Where can I find the benchmarks? 

I just run a very simple benchmark on 112MB document (http://www.xml-be
nchmark.org/downloads.html) and results are quite the opposite: 

Benchmark resut:
Generated at :14-07-2016 07:32:25 AM

   Benchmark  Execution Time [ms]  # of M&S GCs
[1]  # of newspace GCs [1]   Parameters
BenchmarkXML
SAX -
VW93418 0  
 2060   
  SAX -
XMLSuite 9921 0
410   

As you can see, the latter is roughly 10 times faster. 

I agree my implementation which uses Expat is clearly suboptimal 
and need to be improved (for example it does not use a ILC-based 
send to driver so you have a lot of cache misses and does a lot 
of unnecessary memcpy()s, but this can be easily improved)

Jan
  

> But a non-hybrid parser with everything (including the DOM) done in C
> should definitely be faster.
> 
> > Sent: Wednesday, July 13, 2016 at 10:27 AM
> > From: stepharo 
> > To: "Pharo Development List" 
> > Subject: [Pharo-dev] tricks for XML parsing.
> > 
> > Hi guys
> > 
> > these free books may be interesting for you
> > 
> >  http://aosabook.org/
> > 
> > http://aosabook.org/en/posa/parsing-xml-at-the-speed-of-light.html
> > 
> > 
> > stef
> > 
> > 
> > 
> 

[Pharo-dev] Apology: Re: Having comments for pragma?

[Jan Vrany]

Stef, all, 

the post below was written by me, not by Stef as it looks.
Due to some funny bug, my email client messed up with headers when I
saved unfinished mail to "Drafts" and then come back to it later.
Time to change email client. 

I'm very sorry for the confusion this caused. 

Jan


On Wed, 2016-06-29 at 11:21 +0100, stepharo wrote:
> 
> 
> On Tue, Jun 28, 2016 at 8:53 PM, stepharo  wrote:
> > When I implemented annotation support I was initially thinking the
> > same - let's create an instance of CoolAnnotationClass when the
> > code is accepted
> > and then one can add arbitrary code to his CoolAnnotationClass. I
> > quickly realized this is a (very) bad idea. Or, to be precise, it
> > is a bad idea given the
> > environment. So I'd be very careful..
> > can you explain your statement?
> 
> Let me try, this is tricky for me as I'm not good at explaining :-) 
> 
> The problems pop out when one need to load the code back. If
>  gets parsed and stored in
> an annotation container as instance of class Coolish (at compilation
> time),  this means that you just
> introduced a dependency from package of the method which contains the
> annotation to the package of
> Coolish class. This is not (or rather was not in my case) desirable,
> because I need/want to annotate
> methods in kernel with annotations for tools. Kernel should not
> depend or tools - I believe we agree on
> that :-) Note, that this is less of a problem for Java since Java
> loads all code lazily, on demand and in a defined
> way. I personally found it very nice  - though it has some
> (solvable?) issues when this lazy loading is used in Smalltalkish 
> environment such as STX:LIBJAVA)
> 
> You can indeed parse them and store them as raw data and convert them
> on demand in reflective
> API. Then, if the class is not available what to do? Return an
> instance of generic Pragma? 
> Throw an error? When one starts to put an arbitrary code into the
> annotation object itself it's either
> processing  code only access data  or it somehow fiddles about the
> annotation itself and/or (worse!)
> about the method itself. The latter results in difficult to debug
> problems as the time the code is executed
> is undefined (if you use lazy instantiation to avoid dependency
> problem). This may be fine with 
> most Smalltalkers as there are other pieces of code that execute
> randomly in an undefined order and still 
> very few complain :-) but I did not want to make things even worse. 
> For the former, mere data-accessing processing code, I don't see much
> of a difference by putting it 
> somwhere else. Follows the same logic as visitor, instead of putting
> code to nodes, you put them
> to extra visitor class. 
> 
> Eliot's design elegantly avoid these problems (the same way Java does
> :-) by simply having one defined
> structure which keeps the logical type of the annotation as data (the
> selector of the message send).
> It has other problems, but not the one above. 
> 
> Not sure if it makes sense, but I did my best :-) I'm not saying it's
> not solvable and you cannot have
> class per annotation type, but it is not **that** easy to get it
> right. This is my experience over the years. 
> 
> HTH, Jan
> 
> > 
> > Stef
> > 
> > 
> > 
> > Jan
> > 
> > P.S.: As for "which always forced me to hate Java": I found myself
> > a very enlightening to think carefully about why somebody else
> > do things differently before I start to hate her/him. Besides,
> > there's whole lot of things that Java guys got right...
> > 
> > 
> > 

Re: [Pharo-dev] Having comments for pragma?

[Jan Vrany]

On Mon, Jun 27, 2016 at 1:09 PM, Nicolas Passerini 
 wrote:



On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov 
 wrote:


2016-06-27 13:28 GMT+02:00 Nicolas Passerini :
That is not quite true, annotations are (kind of) objects but you 
can not put behavior in them, just define attributes and optionally 
default values for those attributes.


Ah, you are right. I remember many restrictions was applied to them 
which always forced me to hate Java :)


Yep.


Well, there's a reason why they're restricted. Note, that the 
restriction is on language level, not at runtime level. A annotation 
class
with arbitrary code would pass JVM verification (or at least I can't 
see a rule that would reject such a class).


When I implemented annotation support I was initially thinking the same 
- let's create an instance of CoolAnnotationClass when the code is 
accepted
and then one can add arbitrary code to his CoolAnnotationClass. I 
quickly realized this is a (very) bad idea. Or, to be precise, it is a 
bad idea given the

environment. So I'd be very careful..

Jan

P.S.: As for "which always forced me to hate Java": I found myself a 
very enlightening to think carefully about why somebody else
do things differently before I start to hate her/him. Besides, there's 
whole lot of things that Java guys got right...

Re: [Pharo-dev] Having comments for pragma?

[Jan Vrany]

In Java you *cannot* annotate any language element. You can annotate 
class, methods, instance variables, method arguments and temporaries 
and packages.



Then when I take an annotation, for example an hibernate annotation:
@Entity
@Table(name = "EMPLOYEE")
In the case of Hibernate, these annotation are for a class and they 
are used at *runtime* to bind the class instances with database 
entries (elements of this class are stored in the table EMPLOYEE).


Now I've never seen anyone doing that, but as you can access the 
annotation at runtime, and you can extract from the annotation its 
name and its parameters (for example you could extract "Table" and 
"name -> EMPLOYEE". Then, using the Java reflective features, you can 
do something like:


method = obj.getClass().getMethod(methodName, param1.class, 
param2.class, ..);

method.invoke(obj, arg1, arg2,...);
And this way you execute a method named "Table", "name" or "EMPLOYEE" 
with the parameter you want, as you could execute a method from any 
string matching a method name. We have the same primitive in Pharo on 
CompiledMethod.



I would not say that pragmas are more powerful in Java. Can you give 
an example of something you can do with the Java annotation that you 
can't do with Pharo pragmas ?


Out of a curiosity,  how can I annotate class, instance variable, 
method argument or temporary, or package.
How can I annotate the pragma definition itself? How can I retrieve 
annotations of a pragma definition?


I mean, I understand that you can *achieve* same effect, but you *can* 
achieve it as well with no pragma support at all.


Jan

In Slang we use pragma to annotate argument and temporary variables 
and it works just fine. When you describe in Pharo classes and 
instance variables using Magritte you can do the same thing as just 
annotating them.





Stef

Re: [Pharo-dev] Official packages on pharo.com - broken

[Jan Vrany]

On Fri, Jun 17, 2016 at 2:56 PM, Peter Uhnak  wrote:

On Fri, Jun 17, 2016 at 03:24:37PM +0200, Sven Van Caekenberghe wrote:


 > On 17 Jun 2016, at 15:15, Petr Fischer  
wrote:

 >
 > It's due to my obscure OS (‎FreeBSD, latest). They have Linux 
compatibility (even 64bits soon), so it's nice, but libs are from 
CentOS6 (now) with glibc 2.12 etc etc.

 >
 > But disfunct downloads on pharo.org is bad. ‎Removing obsolete 
thinks from official website is not bad idea.


 It is not dysfunctional, it is legacy, that is important too.


It is dysfunctional in the sense that it claims it's for Pharo 5, 
which is no longer true since December (or whenever we've switched to 
Spur).


The action should be either:

a) remove the link altogher
b) say that it's only for Pharo 4 (if you want to support legacy)

In addition to that, if you want backward compatiblity (legacy 
argument here imho fails, because Pharo 5 has been released a month 
ago)


1) build spur with glibc <2.15 and add it as a download for Pharo 5


There is such a VM: 
https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/ in case you 
need it.


Jan




I think there's no point in doing this as you are just increasing 
maintenance/legacy burden down the road, but I wouldn't be the one 
doing that so that's not my call.


Peter

Re: [Pharo-dev] endless loop again

[Jan Vrany]

 IMHO, all Pharo beginner tutorials should start by showing off Cmd 
- dot (or Alt - dot, on Win / Linux).


 Not just because it's cool, but because it's necessary :)

 Cheers,
 Henry


Very true.

Yet, and I have already mentioned this years ago, it is technically 
totally possible to properly detect massive stack growth, before 
things get out of control. Sadly, VM people think this is not needed 
(or too costly).


Not entirely true :-) There are smalltalks out there that detect such 
stack growth and do the same as CL,
throw a (resumable) exception. Super-handy. Some of them have this for 
at least 10 years now :-)


And, it could be done with virtually no costs at all - hardware check 
for this anyway.


Jan

Re: [Pharo-dev] XMLParser changes

[Jan Vrany]

Not sure whether this was an intention. but strictly speaking, 
new behavior is correct. 
See Extensible Markup Language (XML) 1.0 (Fifth Edition), 
Section 2.10 White Space Handling:

"An XML processor must always pass all characters in a document that
are not markup through to the application. A validating XML processor
must also inform the application which of these characters constitute
white space appearing in element content."

Jan



On Mon, 2016-04-25 at 12:14 +0200, Cyril Ferlicot Delbecque wrote:
> Hi,
> 
> last week there was a new stable version of XMLParser and some tests
> broke in some tools. I think that there was a regression in this
> version.
> 
> Snippet:
> 
> (XMLDOMParser parse: '
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ') elements first nodes
> 
> With the release 2.7.4 we get 2 nodes but in release 2.7.6 we get 5
> nodes. The 2 previous ones and 3 empty String nodes.
> 
> I think this is not what we expect. Correct me if I am wrong :)
> 
> 

[Pharo-dev] ANN - Pre-compiled Pharo Spur32 VM for Debian Stable

[Jan Vrany]

Hi there, 

the Pharo Spur VM provided by the Pharo team does not run 
Debian Stable and possibly on other more conservative Linux
distributions. 

You may find a pre-compiled Spur32 Pharo VM that runs on 
Debian Stable (and possibly on other distros) at: 

https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/

Zeroconf for those is also available: 

curl http://swing.fit.cvut.cz/download/pharo/vm-spur-swing | bash
wget -O- http://swing.fit.cvut.cz/download/pharo/vm-spur-swing | bash

Thanks a lot to Esteban and Damien for their help!

Have fun! 
Jan

Re: [Pharo-dev] [Ann] ReadWriteLock

[Jan Vrany]

Denis, 

yes, I read it, but I could not find answers there. 

Ben,

thanks! The second article suggests that readers may do
blocking operations inside read-critical sections such as IO.
If the critical section may block, then I see the advantage.
I always thought doing a blocking operation in a critical section
is no-no so I haven't considered that case...Thanks! 

Best, Jan



On Wed, 2016-01-13 at 11:31 +0800, Ben Coman wrote:
> These two read together provide a balanced view.
> 
> ReaderWriterLock vs Monitor
> http://www.interact-sw.co.uk/iangblog/2004/04/26/rwlockvsmonitor
> 
> When to use the ReaderWriterLock
> https://www.interact-sw.co.uk/iangblog/2004/05/12/rwlock
> 
> cheers -ben
> 
> On Wed, Jan 13, 2016 at 6:27 AM, Jan Vrany 
> wrote:
> > Hi Denis, all,
> > 
> > I'm sorry for asking basic questions, but...
> > 
> > I thought of this a little and I failed to see the advantage
> > of using ReadWriteLock over monitor / mutex. What's the goal
> > of ReadWriteLock? I mean - when should I use it rather than
> > monitor / mutex? What practical advantage would it have?
> > 
> > Best, Jan
> > 
> > 
> > On Mon, 2016-01-04 at 18:39 +0100, Denis Kudriashov wrote:
> > > Hi.
> > > 
> > > I implemented small package ReadWriteLock http://smalltalkhub.com
> > > /mc/
> > > Pharo/ReadWriteLock/main.
> > > 
> > > Gofer it
> > >   smalltalkhubUser: 'Pharo' project: 'ReadWriteLock';
> > >   configurationOf: 'ReadWriteLock';
> > >   loadStable
> > > 
> > > It is reentral read write lock which described in
> > > https://en.wikipedia.org/wiki/Readers–writer_lock. From the artic
> > > le:
> > > 
> > > > An ReadWriteLock allows concurrent access for read-only
> > > > operations,
> > > > while write operations require exclusive access. This means
> > > > that
> > > > multiple threads can read the data in parallel but an exclusive
> > > > lock is needed for writing or modifying data. When a writer is
> > > > writing the data, all other writers or readers will be blocked
> > > > until the writer is finished writing.
> > > Public API and Key Messages
> > > 
> > > - lock := ReadWriteLock new
> > > - lock criticalRead: aBlock
> > > - lock criticalWrite: aBlock
> > > 
> > > Implementation based on two semaphores and readers counter.
> > > 
> > > Main difficulty is carefully handle process termination during
> > > execution of critical sections. This problem described in
> > > Semaphore>>critical: comment. Same approach is used here. But
> > > synchronisation logic around two semaphores for reading and
> > > writing
> > > complicates things very much. No simple way to decompose logic on
> > > multiple methods because information about process interruption
> > > become hidden.
> > > From the Semaphore comment:
> > > > The main trick is assignment right before we go into the wait
> > > > primitive (which is not a real send and therefore not
> > > > interruptable
> > > > either). So after we can check that waiting is happen or not.
> > > Tests are implemented only for lock scenarios. No tests for
> > > described
> > > termination process cases. It is not really clear how to write
> > > it.
> > > I will be appreciate if people review code. Maybe you will
> > > suggest
> > > simplifications. It is always difficult to implement concurrent
> > > code.
> > > 
> > > Best regards,
> > > Denis
> > 
> 
> 

Re: [Pharo-dev] [Ann] ReadWriteLock

[Jan Vrany]

Hi Denis, all, 

I'm sorry for asking basic questions, but...

I thought of this a little and I failed to see the advantage 
of using ReadWriteLock over monitor / mutex. What's the goal
of ReadWriteLock? I mean - when should I use it rather than 
monitor / mutex? What practical advantage would it have? 

Best, Jan


On Mon, 2016-01-04 at 18:39 +0100, Denis Kudriashov wrote:
> Hi.
> 
> I implemented small package ReadWriteLock http://smalltalkhub.com/mc/
> Pharo/ReadWriteLock/main.
> 
> Gofer it 
>   smalltalkhubUser: 'Pharo' project: 'ReadWriteLock';
>   configurationOf: 'ReadWriteLock';
>   loadStable
> 
> It is reentral read write lock which described in 
> https://en.wikipedia.org/wiki/Readers–writer_lock. From the article:
> 
> > An ReadWriteLock allows concurrent access for read-only operations,
> > while write operations require exclusive access. This means that
> > multiple threads can read the data in parallel but an exclusive
> > lock is needed for writing or modifying data. When a writer is
> > writing the data, all other writers or readers will be blocked
> > until the writer is finished writing.
> Public API and Key Messages
> 
> - lock := ReadWriteLock new
> - lock criticalRead: aBlock
> - lock criticalWrite: aBlock
> 
> Implementation based on two semaphores and readers counter. 
> 
> Main difficulty is carefully handle process termination during
> execution of critical sections. This problem described in
> Semaphore>>critical: comment. Same approach is used here. But
> synchronisation logic around two semaphores for reading and writing
> complicates things very much. No simple way to decompose logic on
> multiple methods because information about process interruption
> become hidden.
> From the Semaphore comment:
> > The main trick is assignment right before we go into the wait
> > primitive (which is not a real send and therefore not interruptable
> > either). So after we can check that waiting is happen or not.
> Tests are implemented only for lock scenarios. No tests for described
> termination process cases. It is not really clear how to write it.  
> I will be appreciate if people review code. Maybe you will suggest
> simplifications. It is always difficult to implement concurrent
> code. 
> 
> Best regards,
> Denis

Re: [Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

[Jan Vrany]

> Maybe it should only lock the threads that were _not_ started by the
> “test thread”? I’m not even sure that is possible,
> just suggesting things.
> 

Have a look at Niall Ross' XProc Patterns. They do the same by - AFAIK
- intercepting process creation and checking whether the creating
process is one of the "tests threads". 

HTH, Jan


> > On Jan 12, 2016, at 11:11 AM, Sven Van Caekenberghe 
> > wrote:
> > 
> > The coverage seems to be implemented by 'locking' the current
> > execution thread exclusively, which would mean no other threads can
> > run, at all. So code depending on multi threading, like
> > client/server code, like HTTP, cannot work. Yes that seems to be a
> > limitation, but an understandable one.
> > 
> > I am trying to help but I don't known anything about the coverage
> > tool, so maybe I should shut up ;-)
> > 
> > > On 12 Jan 2016, at 11:05, Skip Lentz  wrote:
> > > 
> > > You mean as in it can check the coverage effected by the code
> > > running in the other thread?
> > > Or is this not what you mean?
> > > 
> > > Well I mean, at least it can show the coverage done by what was
> > > run in the same thread..
> > > And it will at least not hang or fail.
> > > 
> > > > On Jan 12, 2016, at 10:59 AM, Sven Van Caekenberghe  > > > eu> wrote:
> > > > 
> > > > I never used that, but it seems coverage can only deal with
> > > > single threaded code, which sounds logical. No ?
> > > > 
> > > > > On 12 Jan 2016, at 10:53, Skip Lentz 
> > > > > wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > When I want to run the coverage of for example Zinc’s Client
> > > > > and Server tests,
> > > > > it will either hang (in the case of Zinc’s test cases) or
> > > > > fail because the coverage
> > > > > uses BlockClosure>>valueUnpreemptively for running the tests.
> > > > > The relevant method is TestRunner>>collectCoverageFor:.
> > > > > 
> > > > > So when a test is run, it is not able to be preempted by
> > > > > another process, like for
> > > > > example a local server which is needed to run the actual test
> > > > > in Zinc’s case.
> > > > > 
> > > > > When I use BlockClosure>>valueUninterruptably it works. Can
> > > > > someone tell me
> > > > > if it is wrong to use that instead? Is valueUnpreemptively
> > > > > necessary in this case,
> > > > > and if so, why?
> > > > > 
> > > > > To reproduce: Load fresh image, select Zinc's ZnClientTests
> > > > > and ZnServerTests,
> > > > > click on “Run Coverage” -> hanging image.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Skip
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 

Re: [Pharo-dev] AsmJit

[Jan Vrany]

Hi Eliot,

> What's the use case?  What do you mean "copy to VM code space"?  I
> want to know because I want to give you a viable direction, but I
> need to know more about your intended use first.

I really appreciate it, but to make it clear: I'm not going
to use Cog/Spur VMs for these experiments. 

By "copy to VM code space" I mean installing a code into 
the area in which VM keeps machine code. I think you call
this "code zone" in Cog. This effectively allows me to 
generate a code for a method from the "image" itself. 

Jan


>  
> >  
> > Thanks! Jan
> > 
> > 
> > 
> > On Tue, 2015-12-15 at 18:34 +0100, Clément Bera wrote:
> > > We're getting away from Jan initial question here ...
> > >
> > > I think the point here is that Cog has:
> > > - 2 stable back ends: ARMv5 and x86 
> > > - 2 backends stable in the simulator with production planned for
> > ~
> > > April: x64 and MIPS
> > > and Tim is willing to do the ARMv8 backend.
> > >
> > > All the 4, and soon 5, cog back ends are maintained:
> > > - x86 and x64 maintained by Eliot
> > > - MIPS maintained by Ryan
> > > - ARMv5 and soon ARMv8 maintained by Tim
> > >
> > > Each backend requires months of work.
> > >
> > > Do you want to maintain 10 backends instead of 5 ? Do want to
> > spend
> > > time to implement 5 backends or 10 ?
> > >
> > > I don't. Only the x86 backend is duplicated right now in AsmJIT.
> > >
> > > So one idea is to reuse Cog's backends from the image instead of
> > > AsmJIT. To do so, we can use encodings available in the sista
> > > extended instruction set to tell Cog what machine code to
> > generate. A
> > > project named uFFI aims, among other things, at doing this, by
> > > providing a unified interface between the Cog backends and
> > AsmJIT.
> > >
> > >
> > > 2015-12-15 16:43 GMT+01:00 Eliot Miranda  > >:
> > > > Hi Jan,
> > > >
> > > > > On Dec 15, 2015, at 3:06 AM, Jan Vrany  > >
> > > > wrote:
> > > > >
> > > > > Hi guys,
> > > > >
> > > > > two queations:
> > > > >
> > > > > (i) Is AsmJit going to be developed any more or it's
> > abandoned
> > > > >     as well as native boost?
> > > >
> > > > AsmJIT is effectively being abandoned but NativeBoost is not.
> > > >
> > > > The key limitation of AsmJIT is that it was not designed to be
> > > > cross platform; it is effectively an x86 assembler.  As such
> > it's
> > > > use gets in the way of ARM and x86_64 (I am currently getting
> > the C
> > > > version of 64-bit Cog Spur working on x86_64, given that it is
> > > > working in the simulator).
> > > >
> > > > Another limitation is that it doesn't play that well with the
> > VM's
> > > > JIT.  Igor and I never managed to work on integrating it
> > better. 
> > > > The VM's job is managing code and Igor's approach was to hack;
> > > > eliminating execution protection in the entire heap, instead of
> > > > extending the support that either the Alien plugin's callback
> > > > support or the JIT's executable method zone provides.  Making
> > the
> > > > entire heap executable is /not/ a sensible approach.
> > > >
> > > > But there is a better way!  A key component of the Sista
> > adaptive
> > > > optimizer/speculative inlined that Clément is currently
> > stabilizing
> > > > (!!) is a set of bytecodes that encode unsafe operations like
> > > > at:put: without bounds, type or store checks.  For example, the
> > > > normal at:put: is about a hundred instructions, checks for
> > > > smallinteger indices, differentiates between byte, 32-but long
> > and
> > > > pointer objects and does a store check. But one of the Sista
> > codes
> > > > for at:put: generates about two instructions, one to adjust the
> > > > index, the other to do the store.  Distaste job is to analyze
> > code
> > > > and inline methods using these unsafe bytecodes where they are
> > > > proven to be safe, hence increasing performance.
> > > >
> > > > Unlike AsmJIT, Sista's unsafe bytecodes are cross platform,
> > and,
> > > > being executed by the VM, can work on an interpreter VM or be
> > > > converted to machine code by the JIT.
> > > >
> > > > So our plan is to extend these bytecodes with ones that support
> > > > marshaling arguments for NativeBoost calls.  Ronie Salgado has
> > > > already extended his lowcode scheme to define these
> > instructions
> > > > and sometime soon (hopefully 2016) we shall rewrite NativeBoost
> > to
> > > > target these bytecodes.
> > > >
> > > > HTH
> > > >
> > > > > (ii)Where can I find latest AsmJit? I'm properly confused:
> > > > >
> > > > >     * Is is the one in latest Pharo 4.0 (5.0) image?
> > > > >     * Is it the one here: http://smalltalkhub.com/#!/~Pharo/A
> > smJi
> > > > t ?
> > > > >       (the one in the image seem to be based on completely
> > > > disjunct
> > > > >        set of .mcz than those in the repo above).
> > > > >
> > > > > Best, Jan
> > > >
> > > > _,,,^..^,,,_ (phone)
> > > >
> > 
> > 
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

Re: [Pharo-dev] AsmJit

[Jan Vrany]

Hi Esteban, Eliot, Clemont

thanks very much for elaborate answer. I'm aware of all what you said
(well, most :-), but my actual needs are very low and primitive. 

All I need now is something that allows me to turn x86_64 assembly 
into a machine code using a sane Smalltalk API, which I can later copy
to VM code space. Nothing more, nothing less :-) I do not fancy
spending time writing yet-another-x86-assembler hence my interest in 
asmjit. 

Thanks! Jan



On Tue, 2015-12-15 at 18:34 +0100, Clément Bera wrote:
> We're getting away from Jan initial question here ...
> 
> I think the point here is that Cog has:
> - 2 stable back ends: ARMv5 and x86 
> - 2 backends stable in the simulator with production planned for ~
> April: x64 and MIPS
> and Tim is willing to do the ARMv8 backend.
> 
> All the 4, and soon 5, cog back ends are maintained:
> - x86 and x64 maintained by Eliot
> - MIPS maintained by Ryan
> - ARMv5 and soon ARMv8 maintained by Tim
> 
> Each backend requires months of work.
> 
> Do you want to maintain 10 backends instead of 5 ? Do want to spend
> time to implement 5 backends or 10 ?
> 
> I don't. Only the x86 backend is duplicated right now in AsmJIT.
> 
> So one idea is to reuse Cog's backends from the image instead of
> AsmJIT. To do so, we can use encodings available in the sista
> extended instruction set to tell Cog what machine code to generate. A
> project named uFFI aims, among other things, at doing this, by
> providing a unified interface between the Cog backends and AsmJIT.
> 
> 
> 2015-12-15 16:43 GMT+01:00 Eliot Miranda :
> > Hi Jan,
> > 
> > > On Dec 15, 2015, at 3:06 AM, Jan Vrany 
> > wrote:
> > >
> > > Hi guys,
> > >
> > > two queations:
> > >
> > > (i) Is AsmJit going to be developed any more or it's abandoned
> > >     as well as native boost?
> > 
> > AsmJIT is effectively being abandoned but NativeBoost is not.
> > 
> > The key limitation of AsmJIT is that it was not designed to be
> > cross platform; it is effectively an x86 assembler.  As such it's
> > use gets in the way of ARM and x86_64 (I am currently getting the C
> > version of 64-bit Cog Spur working on x86_64, given that it is
> > working in the simulator).
> > 
> > Another limitation is that it doesn't play that well with the VM's
> > JIT.  Igor and I never managed to work on integrating it better. 
> > The VM's job is managing code and Igor's approach was to hack;
> > eliminating execution protection in the entire heap, instead of
> > extending the support that either the Alien plugin's callback
> > support or the JIT's executable method zone provides.  Making the
> > entire heap executable is /not/ a sensible approach.
> > 
> > But there is a better way!  A key component of the Sista adaptive
> > optimizer/speculative inlined that Clément is currently stabilizing
> > (!!) is a set of bytecodes that encode unsafe operations like
> > at:put: without bounds, type or store checks.  For example, the
> > normal at:put: is about a hundred instructions, checks for
> > smallinteger indices, differentiates between byte, 32-but long and
> > pointer objects and does a store check. But one of the Sista codes
> > for at:put: generates about two instructions, one to adjust the
> > index, the other to do the store.  Distaste job is to analyze code
> > and inline methods using these unsafe bytecodes where they are
> > proven to be safe, hence increasing performance.
> > 
> > Unlike AsmJIT, Sista's unsafe bytecodes are cross platform, and,
> > being executed by the VM, can work on an interpreter VM or be
> > converted to machine code by the JIT.
> > 
> > So our plan is to extend these bytecodes with ones that support
> > marshaling arguments for NativeBoost calls.  Ronie Salgado has
> > already extended his lowcode scheme to define these instructions
> > and sometime soon (hopefully 2016) we shall rewrite NativeBoost to
> > target these bytecodes.
> > 
> > HTH
> > 
> > > (ii)Where can I find latest AsmJit? I'm properly confused:
> > >
> > >     * Is is the one in latest Pharo 4.0 (5.0) image?
> > >     * Is it the one here: http://smalltalkhub.com/#!/~Pharo/AsmJi
> > t ?
> > >       (the one in the image seem to be based on completely
> > disjunct
> > >        set of .mcz than those in the repo above).
> > >
> > > Best, Jan
> > 
> > _,,,^..^,,,_ (phone)
> > 

[Pharo-dev] AsmJit

[Jan Vrany]

Hi guys, 

two queations: 

(i) Is AsmJit going to be developed any more or it's abandoned
    as well as native boost?

(ii)Where can I find latest AsmJit? I'm properly confused:

    * Is is the one in latest Pharo 4.0 (5.0) image?
    * Is it the one here: http://smalltalkhub.com/#!/~Pharo/AsmJit ?
      (the one in the image seem to be based on completely disjunct
       set of .mcz than those in the repo above).

Best, Jan

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

[Jan Vrany]

Oops, sorry - accidentally sent unfinished message

Another slim implementation of Cypress decoupled from Monticello
is the one I wrote for St/X:

https://bitbucket.org/janvrany/stx-goodies-cypress/src

or in Cypress format itself: 

https://github.com/CampSmalltalk/Cypress/tree/master/implementations/sm
alltalkx/packages/stx_goodies_cypress.package
though this might be a little behind, I'll check an eventually 
update soon(ish)

It has the nice feature of keeping all files and properties it does 
not understand, though this behaviour is *not* required by 
Cypress spec. 

Best, Jan
> 
> On Wed, 2015-11-25 at 21:42 +0100, Thierry Goubier wrote:
> > Hi Dale,
> > 
> > thanks for the update. So not only it would be possible to extract 
> > FileTree from its relation to Monticello, this has in fact already
> > been 
> > done (and more than once).
> > 
> > Thierry
> > 
> > Le 25/11/2015 20:33, Dale Henrichs a écrit :
> > > 
> > > 
> > > On 11/25/2015 02:31 AM, Thierry Goubier wrote:
> > > > 
> > > > 
> > > > 2015-11-25 10:39 GMT+01:00 Skip Lentz  > > > >:
> > > > 
> > > > 
> > > > > I think having a FileTree reader/writer that is not
> > > > > coupled
> > > > > to Monticello would be good, but maybe I’m saying
> > > > > something
> > > > > that is not possible.
> > > > > 
> > > > > 
> > > > > No, it is possible (everything is), but a bit complex for
> > > > > maintenance (how do you track changes and corrections in
> > > > > the
> > > > > FileTree code?).
> > > > 
> > > > Of course, the sky is the limit :P. Although I’m not sure I
> > > > understand what you mean here, could you explain?
> > > > 
> > > > FileTree has a large set of test cases, sample repositories, CI
> > > > setup,
> > > > cross-platform knowledge, bug fixes coming from a large group
> > > > of
> > > > users
> > > > (far larger than the Pharo community).
> > > > 
> > > > Cutting ourselves from that is counter productive and looks
> > > > like
> > > > a
> > > > case of the NIH syndrome.
> > > > 
> > > 
> > > Thierry,
> > > 
> > > I understand where you are coming from with your comment and I am
> > > not
> > > necessarily disagreeing with you, but:)
> > > 
> > > A "FileTree reader/writer that is not coupled to Monticello" is
> > > not
> > > necessarily a bad thing and in fact I have implemented such a
> > > beast
> > > a
> > > couple of times[1][2] and I think that Jan based his initial
> > > implementation on the Pharo Cypress implementation[5].
> > > 
> > > My initial implementation[1] was done in support of Amber
> > > Skeleton[3][6]
> > > where I added implemented an Amber source code server in Pharo
> > > and
> > > used
> > > the Cypress reader/writer[1] to pass packages back and forth
> > > between
> > > Amber and Pharo once the package hit Pharo it was written to disk
> > > using
> > > FileTree.
> > > 
> > > The second implementation[2] was done to implement a FileTree
> > > reader/writer for Cuis which does not use Monticello, so I needed
> > > a
> > > reader/writer that understood the FileTree disk format without
> > > being
> > > coupled to the Monticello package implementation and loader.
> > > 
> > > Richard Sargent has a Cypress reference implementation for
> > > GemStone
> > > that
> > > is also independent of Monticello[4].
> > > 
> > > These Cypress implementations read/write the FileTree disk format
> > > without being coupled to the in-image Monticello implementation
> > > ...
> > > the
> > > definition model and loaders are basically stripped down versions
> > > of the
> > > Monticello implementations, with the major difference being the
> > > absence
> > > of the Monticello meta data --- ancestors and the like --- which
> > > means
> > > that in a world where you rely on the disk-based scm to manage
> > > versions,
> > > there is no need to have the Monticello meta data in the image at
> > > all ...
> > > 
> > > Skip will be downloading individual files from GitHub and will
> > > need
> > > to
> > > construct a coherent package model from those files and
> > > directories.
> > > There may be an advantage to constructing "Cypress snapshots"
> > > from
> > > the
> > > raw GitHub data as an intermediate format if nothing else - much
> > > as
> > > I
> > > did for the Amber Skeleton project 
> > > 
> > > If there is interest in moving forward with the Pharo Cypress
> > > code[1], I
> > > would be in favor of splitting that code out into a separate
> > > project, so
> > > that it can evolve independent of it's Amber Skeleton roots ...
> > > 
> > > Dale
> > > 
> > > [1]
> > > https://github.com/CampSmalltalk/Cypress/tree/master/implementati
> > > on
> > > s/pharo/cypress/packages
> > > [2]
> > > https://github.com/CampSmalltalk/Cypress/tree/master/implementati
> > > on
> > > s/cuis/packages
> > > [3] https://github.com/dalehenrich/amber-skeleton/tree/master/ser
> > > ve
> > > r
> > > [4] https://github.com/rjsargent/CypressReferenceImplementation
> > > [5]
>

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

[Jan Vrany]

Another slim implementation of Cypress decoupled from Monticello
is the one I wrote for St/X:

https://bitbucket.org/janvrany/stx-goodies-cypress/src

or in Cypress format itself: 



On Wed, 2015-11-25 at 21:42 +0100, Thierry Goubier wrote:
> Hi Dale,
> 
> thanks for the update. So not only it would be possible to extract 
> FileTree from its relation to Monticello, this has in fact already
> been 
> done (and more than once).
> 
> Thierry
> 
> Le 25/11/2015 20:33, Dale Henrichs a écrit :
> > 
> > 
> > On 11/25/2015 02:31 AM, Thierry Goubier wrote:
> > > 
> > > 
> > > 2015-11-25 10:39 GMT+01:00 Skip Lentz  > > >:
> > > 
> > > 
> > > > I think having a FileTree reader/writer that is not
> > > > coupled
> > > > to Monticello would be good, but maybe I’m saying
> > > > something
> > > > that is not possible.
> > > > 
> > > > 
> > > > No, it is possible (everything is), but a bit complex for
> > > > maintenance (how do you track changes and corrections in
> > > > the
> > > > FileTree code?).
> > > 
> > > Of course, the sky is the limit :P. Although I’m not sure I
> > > understand what you mean here, could you explain?
> > > 
> > > FileTree has a large set of test cases, sample repositories, CI
> > > setup,
> > > cross-platform knowledge, bug fixes coming from a large group of
> > > users
> > > (far larger than the Pharo community).
> > > 
> > > Cutting ourselves from that is counter productive and looks like
> > > a
> > > case of the NIH syndrome.
> > > 
> > 
> > Thierry,
> > 
> > I understand where you are coming from with your comment and I am
> > not
> > necessarily disagreeing with you, but:)
> > 
> > A "FileTree reader/writer that is not coupled to Monticello" is not
> > necessarily a bad thing and in fact I have implemented such a beast
> > a
> > couple of times[1][2] and I think that Jan based his initial
> > implementation on the Pharo Cypress implementation[5].
> > 
> > My initial implementation[1] was done in support of Amber
> > Skeleton[3][6]
> > where I added implemented an Amber source code server in Pharo and
> > used
> > the Cypress reader/writer[1] to pass packages back and forth
> > between
> > Amber and Pharo once the package hit Pharo it was written to disk
> > using
> > FileTree.
> > 
> > The second implementation[2] was done to implement a FileTree
> > reader/writer for Cuis which does not use Monticello, so I needed a
> > reader/writer that understood the FileTree disk format without
> > being
> > coupled to the Monticello package implementation and loader.
> > 
> > Richard Sargent has a Cypress reference implementation for GemStone
> > that
> > is also independent of Monticello[4].
> > 
> > These Cypress implementations read/write the FileTree disk format
> > without being coupled to the in-image Monticello implementation ...
> > the
> > definition model and loaders are basically stripped down versions
> > of the
> > Monticello implementations, with the major difference being the
> > absence
> > of the Monticello meta data --- ancestors and the like --- which
> > means
> > that in a world where you rely on the disk-based scm to manage
> > versions,
> > there is no need to have the Monticello meta data in the image at
> > all ...
> > 
> > Skip will be downloading individual files from GitHub and will need
> > to
> > construct a coherent package model from those files and
> > directories.
> > There may be an advantage to constructing "Cypress snapshots" from
> > the
> > raw GitHub data as an intermediate format if nothing else - much as
> > I
> > did for the Amber Skeleton project 
> > 
> > If there is interest in moving forward with the Pharo Cypress
> > code[1], I
> > would be in favor of splitting that code out into a separate
> > project, so
> > that it can evolve independent of it's Amber Skeleton roots ...
> > 
> > Dale
> > 
> > [1]
> > https://github.com/CampSmalltalk/Cypress/tree/master/implementation
> > s/pharo/cypress/packages
> > [2]
> > https://github.com/CampSmalltalk/Cypress/tree/master/implementation
> > s/cuis/packages
> > [3] https://github.com/dalehenrich/amber-skeleton/tree/master/serve
> > r
> > [4] https://github.com/rjsargent/CypressReferenceImplementation
> > [5]
> > https://github.com/CampSmalltalk/Cypress/tree/master/implementation
> > s/smalltalkx/packages/stx_goodies_cypress.package
> > [6] https://github.com/CampSmalltalk/amber-cypress
> 
> 

Re: [Pharo-dev] [ANN] CalipeL: a benchmarking tool for Smalltalk/X and Pharo

[Jan Vrany]

Hi Stefan, 

OK, you proved I was wrong. I said I could.  
Thanks for clarification!  

Jan


On Thu, 2015-11-05 at 17:17 +0100, smallt...@stefan-marr.de wrote:
> Hi Jan,
> Hi Max:
> 
> I guess, the main issues is missing documentation…
> Even so, there are class comments…
> 
> > On 01 Nov 2015, at 23:45, Jan Vrany  wrote:
> > 
> > Hi Max,
> > 
> > I looked at some version of SMark years ago and never used 
> > it extensively, so I might be wrong, but: 
> > 
> > * SMark executor does some magic with numbers.
> 
> Nope. It does only do that if you ask for it. However, granted,
> that’s the standard setting, because it is supposed to be used
> conveniently from within the image.
> 
> The SMark design knows the concepts reporter (how and what data to
> report), runner (how to execute benchmarks), suite (the benchmarks),
> timer (should be named gauge or something, can be everything, doesn’t
> have to be time).
> 
> 
> > It tries to 
> >   calculate a number of iterations to run in order to get 
> >   "statistically meaningful results". Maybe it's me, but
> >   I could not fully understand what it does and why it does it
> >   so. 
> >   CalipeL does no magic - it gives you raw numbers (no average, no
> > mean,
> >   rather a sequence of measurements).
> 
> See the ReBenchHarness, that’s giving you exactly that as alternative
> standard setting.
> 
> > * SMark, IIRC, requires benchmarks to inherit from some base class
> >   (like SUnit).
> 
> Require is a strong word, as long as you implement the interface of
> SMarkSuite you can inherit from where ever you want. It’s Smalltalk
> after all.
> 
> 
> > Also, not sure if SMark allows you to specify a warmup-
> >   phase (handy for example to measure peak performance when caches
> > are
> >   filled or so). 
> 
> There is the concept of #setup/teardown methods.
> And, a runner can do what it wants/needs to reach warmup, too.
> For instance, the SMarkCogRunner will make sure that all code is
> compiled before starting to measure.
> 
> >   CalipeL, OTOH, uses method annotations to describe the benchmark,
> >   so one can turn a regular SUnit test method into benchmark as
> > simply
> >   as annotating it with .
> 
> Ok, that’s not possible.
> 
> > A warmup method and setup/teardown
> >   methods can be specified per-benchmark. 
> 
> We got that too.
> 
> > * SMark has no support for parametrization. 
> 
> Well, there is the #problemSize parameter, but that is indeed rather
> simplistic.
> 
> > 
> > * SMark measures time only. 
> 
> Nope, the SMarkTimer can measure what they want. (and it even got a
> class comment ;))
> 
> > * SMark had no support for “system" profilers and similar. 
> 
> That’s absent, true.
> 
> > * Finally, SMark spits out a report and that’s it. 
> 
> Well, reports and raw data. I use ReBench [1], and pipe the raw data
> directly into my latex/knitr/R tool chain to generate graphs/numbers
> in my papers (example sec. 4 [2], that’s based on a latex file with
> embedded R).
> 
> So, I’d say there are some interesting differences.
> But, much of the mentioned things seem just to be missing
> ‘documentation’/communication ;)
> 
> Best regards
> Stefan
> 
> [1] https://github.com/smarr/ReBench
> [2] http://stefan-marr.de/papers/oopsla-marr-ducasse-meta-tracing-vs-
> partial-evaluation/
> 
> 
> 
> 
> 

Re: [Pharo-dev] [ANN] CalipeL: a benchmarking tool for Smalltalk/X and Pharo

[Jan Vrany]

Hi Max,

I looked at some version of SMark years ago and never used 
it extensively, so I might be wrong, but: 

* SMark executor does some magic with numbers. It tries to 
  calculate a number of iterations to run in order to get 
  "statistically meaningful results". Maybe it's me, but
  I could not fully understand what it does and why it does it
  so. 
  CalipeL does no magic - it gives you raw numbers (no average, no
mean,
  rather a sequence of measurements). It's up to the one who processes
and
  interprets the data to use whatever method she likes (and whichever
  gives the numbers she'd like to see :-) This transparency was 
  important for our needs. 

* SMark, IIRC, requires benchmarks to inherit from some base class
  (like SUnit). Also, not sure if SMark allows you to specify a warmup-
  phase (handy for example to measure peak performance when caches are
  filled or so). 
  CalipeL, OTOH, uses method annotations to describe the benchmark,
  so one can turn a regular SUnit test method into benchmark as simply
  as annotating it with . A warmup method and setup/teardown
  methods can be specified per-benchmark. 

* SMark has no support for parametrization. 
  In Calipel, support for benchmark parameters was one of the 
  requirements from the very beginning. A little example: 
  I had to optimize performance of Object>>perform: family of methods
  for they was thought to be slowish. I came up with several 
  variants of of a "better" implementation, no knowing which one 
  is the best. How does each of them behave under different workloads? 
  Like - how the number of distinct receivier classes affects the
performance? 
  How the number of distinct selectors affects the performance? 
  Is the performance different when receiver classes are distributed
  uniformly or normally (which seems to be more common case). 
  Same for selectors? Is 256 row, 2-way associative cache
  better than 128 rows, 4-way associative? 
  You have number of parameters, for each parameter you define
  a number of values and CalipeL work out all possible combinations
  and run benchmarks using each. Without parametrization, the number
  of benchmark methods would grow exponentially, making hard 
  to experiment with different setups. For me, this is one of 
  key things. 

* SMark measures time only. 
  CalipeL measures time, too, but has the facility to provide a 
  user-defined "measurement instrument", which can be anything 
  (what can be measured, indeed). For example, for some web 
  application the execution time might not be that useful, perhaps
  a number of SQL queries it makes is more important. No problem, 
  define your own measurement instrument and tell CalipeL to use it
  in addition to time, number of GCs, you name it. All results of 
  all instruments are part of machine-readable report, indeed. 

* SMark had no support for "system" profilers and similar. 
  CalipeL integrates with systemtap/dtrace and cachegrind so one 
  can have a full profile, including VM code and see things like 
  L1/L2 I/D cache misses, mispredicted branches or count events 
  like context switches, monitor signaling, context evacuation. 
  Useful only for VM engineers I think, but I cannot image doing 
  my work without this. Available only for Smalltalk/X, but should
  not be a big deal adding this to Pharo (simple plugin would do it, 
  IMO)

* Finally, SMark spits out a report and that's it. 
  CalipeL, OTOH, goes beyond that. It tries for provide tools 
  to gather, store and query results in a centralised way so 
  nothing is forgotten.
  (no more: hmm, where are the results of #perform: benchmarks
  I run three months ago? Is it this file? Or that file? Or did I 
  deleted them when my laptop run out of disk space?) 
  And yes, I know that in this area there's a lot of space for
  improvements. What we have now is certainly not ideal, to put
  it mildly :-) 


Hope that gives you the idea. 

Jan


On Sun, 2015-11-01 at 12:11 +0100, Max Leske wrote:
> Hi Jan,
> 
> That looks pretty cool!
> We use SMark (http://smalltalkhub.com/#!/~PharoExtras/SMark) for
> benchmarking and CI integration for Fuel. If you know SMark, could
> you give me an idea of what the differences are?
> 
> Cheers,
> Max
> 
> 
> > On 23 Oct 2015, at 10:47, Jan Vrany  wrote:
> > 
> > Hi there,
> > 
> > After more than 2 years of (time-to-time) development and about 
> > that much time of use, I'd like to announce CalipeL, a tool for
> > benchmarking and monitoring performance regressions.
> > 
> > The basic ideas that drove the development:
> > 
> > * Benchmarking and (especially) interpreting benchmark results 
> >   is always a monkey business. The tool should produce raw numbers,
> >   letting the user to use whichever statistics she need to make up
> >   (des

[Pharo-dev] [ANN] CalipeL: a benchmarking tool for Smalltalk/X and Pharo

[Jan Vrany]

Hi there,

After more than 2 years of (time-to-time) development and about 
that much time of use, I'd like to announce CalipeL, a tool for
benchmarking and monitoring performance regressions.

The basic ideas that drove the development:

* Benchmarking and (especially) interpreting benchmark results 
  is always a monkey business. The tool should produce raw numbers,
  letting the user to use whichever statistics she need to make up
  (desired) results.
* Benchmark results should be kept and managed at a single place so
  one can view and retrieve all past benchmark results pretty much 
  the same way as one can view and retrieve past versions of 
  the software from a source code management tool.

Features:

- simple - creating a benchmark is as simple as writing a method 
  in a class
- flexible - a special set-up and/or warm-up routines could be
  specified at benchmark-level as well as set of parameters 
  to allow fine-grained measurements under different conditions
- batch runner - contains a batch runner allowing one to run 
  benchmarks from a command line or at CI servers such as Jenkins.
- web - comes with simple web interface to gather and process 
  benchmark results. However, the web application would deserve
  some more work.

Repository: 

  https://bitbucket.org/janvrany/jv-calipel

  http://smalltalkhub.com/#!/~JanVrany/CalipeL-S (read-only export
  from the above and Pharo-specific code)

More information: 

  https://bitbucket.org/janvrany/jv-calipel/wiki/Home

I have been using CalipeL for benchmarking and keeping track of 
performance of Smalltalk/X VM, STX:LIBJAVA, a PetitParser compiler 
and other code I was working over the time.

Finally, I'd like to thank to Marcel Hlopko for his work on the 
web application and Jan Kurs for his comments.

I hope some of you may find it useful. If you have any comments 
or questions, do not hesitate and let me know!

Regards, Jan

[Pharo-dev] Stream instead of string concatenation

[Jan Vrany]

Hi there, 

it's a little less than a year ago the above issue has been raised 
by Uko [1]. I run some benchmarks (a little less than year ago :-)

With the integration of QA this issue may deserve some attention again.
Besides, Uko asked for a feedback. 

The rule seems to be wrong - it barks on code which is (seems to be) 
perfectly fine performance-wise, For example: 

shutUp
Class allInstances do:[:cls |
Transcript show: 'barking at' , cls name
]

See *some* of the benchmark results: http://bit.ly/1GnZ3K0
My interpretation of the result is the following:

For small number of concatenations, i.e., up to 5, with no
accumulator and with reasonably small strings, i.e., shorter than
50 bytes, 
it's actually faster to use string concatenation. 
Using streams is slower, unless one preallocates stream backing 
string to exactly the size needed. In that case, it's roughly the
same as string concatenation using #,

You may find full benchmark data at: 

https://swing.fit.cvut.cz/calipel/archive/943.json
https://swing.fit.cvut.cz/calipel/archive/944.json

Benchmark source: 

https://bitbucket.org/janvrany/jv-calipel/src/tip/s/benchmarks/micro/Be
nchmarkMicroStringConcat.st?fileviewer=file-view-default

https://bitbucket.org/janvrany/jv-calipel/src/tip/s/benchmarks/micro/Be
nchmarkMicroStringConcatN.st?fileviewer=file-view-default

Indeed, I could have messed up things - we all know about
lies, damn lies and benchmarks.

HTH, Jan


[1]: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-No
vember/103162.html

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Jan Vrany]

On Mon, 2015-09-28 at 16:48 -0700, Dale Henrichs wrote:
> The big issue for git and windows (in general) is that there is a 255
> character limit on the paths for files  I recently pruned some
> file names for Metacello (on a win-hack branch) just to get Metacello
> to work with filetree .. 

The limit is actually 260 characters. Not that it helps much :-)
However, there's a way (well, hack) to overcome this limit 
using special UNC pathnames like 
\\?\C:\very\long\path\here or \\?\UNC\server\share\very\long\path.

The "only" issue is that not all tools in the chain are using 
this hack...

Jan

Re: [Pharo-dev] Help with RBTransformationRule needed!

[Jan Vrany]

> RBTransformationRule (you need to activate that verificationBlock
> when
> you create your rewriter).

Yes, and this is the tricky bit :-) Because there's no guarantee that
this block is functional. For example, it may access context ivar
which, by the time UI is retrieving intervals is already nilled out
or even filled again with some other unrelated context if you're
reusing rule instances (but if not, you may run into performance
problems...)

Re: [Pharo-dev] Help with RBTransformationRule needed!

[Jan Vrany]

Yeah, I remember this is a pain. When I did years ago what 
you're doing now with QA, I ended up practicing black magic, 
sacrificing chickens and other things you'd better not to know.

IIRC, the trick is to turn rewrite rules in ParseTreeEnvironment 
into search rules and then run the searches. Now this is tricky
as these rules quite often refers to blocks, which then refers to outer
contexts and you need these blocks do something different now (report
nodes rather then transform stuff). This is the main problem. 

If you have the guts, you may find the code here: 

https://bitbucket.org/janvrany/stx-goodies-smallsense
and here:
http://swing.fit.cvut.cz/hg/stx.goodies.refactoryBrowser/

(alternatively, downlaod https://swing.fit.cvut.cz/projects/stx-jv/
 and browse the code in Smalltalk browser). 

You may want to trace the code starting from
ParseTreeEnvironment>>selectionIntervalsForSource:tree:do: 
RBParseTreeRule>>copyMatchDo: and implementors is also
worth mentioning. 

After doing this, I concluded that SmallLint as it's now is not
well designed for this task and it would need a significant
refactoring. However, as always, I was never given time to do it.

HTH, Jan


On Tue, 2015-09-22 at 17:56 +0200, Yuriy Tymchuk wrote:
> Hi everyone,
> 
> I need someone who knows how RBParseTreeRewriter & co. work. May of
> quality rules are implemented as rewrite rules which is cool. But
> they don’t report the interval in source code which can be
> highlighted to help with understanding of the issue.
> 
> Now… the check happens in RBTransformationRule>>#checkMethod:. Is it
> possible to obtain the matched string there? Because in that case we
> can get highlighting working which will be very useful.
> 
> Cheers!
> Uko
> 

Re: [Pharo-dev] Need a decision on subString: vs substring:

[Jan Vrany]

Hi,

I'm not sure what's the decision, however, as a pain-relief
 I committed just couple days ago CompatibilityANSI to 
http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility

For now it only defines subStrings: :-) 



On Sun, 2015-09-20 at 16:08 +0200, Stephan Eggermont wrote:
> We have quite a lot of instances of #subString: in Seaside.
> The deprecation makes loading painful.
> What is the decision?
> 
> Stephan
> 
> 

Re: [Pharo-dev] ANSICompatibility package

[Jan Vrany]

On Fri, 2015-09-18 at 23:04 +0800, Ben Coman wrote:
> Thanks for your contribution Jan.  It is interesting how in
> "CompatibilitySmalltalkX class>>initialize" you deal with missing
> classes  by inserting what are essentially alias into the Smalltalk
> dictionary.  So, I'm happy I learnt something new today.
> 
> Just curious though why both the class-side and instance-side
> #initialize methods set the same alias, but different ways.

Well, this is (was) a bug, I by mistake defined the method on instance
side (where it makes no sense). The Nautilus UI is rather stupid in
that respect, not making clear whether what you see is class side 
or instance side...

> 
> Also curious why "ClassDescription>>isClass" is blank. It would seem
> to need a boolean return value.

Accident, should be removed. 

Both issues fixed in Compatibility-SmalltalkX-JanVrany.11
Thanks for spotting! 

Jan

> 
> cheers -ben
> 
> On Fri, Sep 18, 2015 at 10:05 PM, Jan Vrany 
> wrote:
> > Thanks, Ben. Stuff copied.
> > 
> > Cheers, Jan
> > 
> > 
> > On Fri, 2015-09-18 at 21:54 +0800, Ben Coman wrote:
> > > Jan, Thanks for your contribution. Actually I hadn't uploaded
> > > anything
> > > yet since I was waiting on more votes on renaming, but to push
> > > ahead
> > > I
> > > settled on SmalltalkCompatibility [1], since I think the repo can
> > > serve a wider purpose than just ANSI.
> > > 
> > > I added you to the PharoExtras team. Hopefully that works.
> > > 
> > > [1] 
> > > http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility
> > > 
> > > cheers -ben
> > > 
> > > On Fri, Sep 18, 2015 at 7:10 PM, Jan Vrany  > > >
> > > wrote:
> > > > 
> > > > > > I would rename it to SmalltalkCompatibility to
> > > > > > ANSICompatibility
> > > > > > because "Compatibility" is a too general term and could
> > > > > > mean
> > > > > > backward compatibility
> > > > > > of Pharo versions or compatibility to other languages as
> > > > > > well.
> > > > > 
> > > > > That was me :)  I was thinking more broadly that over time
> > > > > the
> > > > > "repository" might  hold different packages Compatibility
> > > > > -ANSI,
> > > > > Compatibility-VW, Compatibility-Dolphin.  But maybe that is
> > > > > overreaching and its better to be more focussed. Let me know
> > > > > what
> > > > > you
> > > > > think on this and restate what you think the repository name
> > > > > should
> > > > > be.
> > > > 
> > > > Ben, could you please give me a commit access? I intend to
> > > > move Compatibility-SmalltalkX and Compatibility-ANSI (which
> > > > I created and "maintain" for my own need). Maybe some others
> > > > may find them useful or maybe even contribute.
> > > > 
> > > > Cheers, Jan
> > > > 
> > > > > 
> > > > > > Also see http://wiki.squeak.org/squeak/2384 and
> > > > > > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32
> > > > > > d338
> > > > > > 9ec
> > > > > > which could be a start.
> > > > > 
> > > > > I saw those, but they interact with existing classes, so I
> > > > > thought it
> > > > > easier to kickstart by loading in the tests first, which are
> > > > > all
> > > > > new
> > > > > classes.  I only created the repository since the tests were
> > > > > *hard*
> > > > > to
> > > > > find eventually at
> > > > > http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-com
> > > > > pati
> > > > > bili
> > > > > ty/
> > > > > So I thought it would be good make them more accessible as a
> > > > > Monticello Package.
> > > > > 
> > > > > cheers -ben
> > > > > 
> > > > > P.S. I don't quite follow "to SmalltalkCompatibility to
> > > > > ANSICompatibility"
> > > > > do you mean "to SmalltalkCompatibility or ANSICompatibility"
> > > > > ?
> > > > > 
> > > > > > 
> > > > > > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr
> > > > > > > Von: stepharo 
> > > > > > > An: "Pharo Development List" 
> > > > > > > Betreff: Re: [Pharo-dev] ANSICompatibility package
> > > > > > > 
> > > > > > > We should have a SmalltalkCompatibility (not Ansi per se)
> > > > > > > package
> > > > > > > were we can add some methods to help migration.
> > > > > > > 
> > > > > > > Stef
> > > > > > > 
> > > > > > > 
> > > > > > > Le 8/9/15 06:04, Ben Coman a écrit :
> > > > > > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <
> > > > > > > > jan.vr...@fit.cvut.cz> wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > is there actually such a thing like ANSICompatibility
> > > > > > > > > package?
> > > > > > > > > (it has been mentioned here lately, but I cannot find
> > > > > > > > > it)
> > > > > > > > > 
> > > > > > > > > Thanks, Jan
> > > > > > > > > 
> > > > > > > > I made it up for the purpose of discussion to see what
> > > > > > > > interest
> > > > > > > > it generated.
> > > > > > > > Should we start one ?
> > > > > > > > cheers -ben
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > > 
> > 
> 
> 

Re: [Pharo-dev] ANSICompatibility package

[Jan Vrany]

Thanks, Ben. Stuff copied.

Cheers, Jan


On Fri, 2015-09-18 at 21:54 +0800, Ben Coman wrote:
> Jan, Thanks for your contribution. Actually I hadn't uploaded
> anything
> yet since I was waiting on more votes on renaming, but to push ahead
> I
> settled on SmalltalkCompatibility [1], since I think the repo can
> serve a wider purpose than just ANSI.
> 
> I added you to the PharoExtras team. Hopefully that works.
> 
> [1] http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility
> 
> cheers -ben
> 
> On Fri, Sep 18, 2015 at 7:10 PM, Jan Vrany 
> wrote:
> > 
> > > > I would rename it to SmalltalkCompatibility to
> > > > ANSICompatibility
> > > > because "Compatibility" is a too general term and could mean
> > > > backward compatibility
> > > > of Pharo versions or compatibility to other languages as well.
> > > 
> > > That was me :)  I was thinking more broadly that over time the
> > > "repository" might  hold different packages Compatibility-ANSI,
> > > Compatibility-VW, Compatibility-Dolphin.  But maybe that is
> > > overreaching and its better to be more focussed. Let me know what
> > > you
> > > think on this and restate what you think the repository name
> > > should
> > > be.
> > 
> > Ben, could you please give me a commit access? I intend to
> > move Compatibility-SmalltalkX and Compatibility-ANSI (which
> > I created and "maintain" for my own need). Maybe some others
> > may find them useful or maybe even contribute.
> > 
> > Cheers, Jan
> > 
> > > 
> > > > Also see http://wiki.squeak.org/squeak/2384 and
> > > > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d338
> > > > 9ec
> > > > which could be a start.
> > > 
> > > I saw those, but they interact with existing classes, so I
> > > thought it
> > > easier to kickstart by loading in the tests first, which are all
> > > new
> > > classes.  I only created the repository since the tests were
> > > *hard*
> > > to
> > > find eventually at
> > > http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compati
> > > bili
> > > ty/
> > > So I thought it would be good make them more accessible as a
> > > Monticello Package.
> > > 
> > > cheers -ben
> > > 
> > > P.S. I don't quite follow "to SmalltalkCompatibility to
> > > ANSICompatibility"
> > > do you mean "to SmalltalkCompatibility or ANSICompatibility" ?
> > > 
> > > > 
> > > > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr
> > > > > Von: stepharo 
> > > > > An: "Pharo Development List" 
> > > > > Betreff: Re: [Pharo-dev] ANSICompatibility package
> > > > > 
> > > > > We should have a SmalltalkCompatibility (not Ansi per se)
> > > > > package
> > > > > were we can add some methods to help migration.
> > > > > 
> > > > > Stef
> > > > > 
> > > > > 
> > > > > Le 8/9/15 06:04, Ben Coman a écrit :
> > > > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <
> > > > > > jan.vr...@fit.cvut.cz> wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > is there actually such a thing like ANSICompatibility
> > > > > > > package?
> > > > > > > (it has been mentioned here lately, but I cannot find it)
> > > > > > > 
> > > > > > > Thanks, Jan
> > > > > > > 
> > > > > > I made it up for the purpose of discussion to see what
> > > > > > interest
> > > > > > it generated.
> > > > > > Should we start one ?
> > > > > > cheers -ben
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > > 
> > 
> 
> 

Re: [Pharo-dev] [review needed] speed up RBClassNotReferencedRule

[Jan Vrany]

On Fri, 2015-09-18 at 14:48 +0200, Marcus Denker wrote:
> > > > 
> > > 
> > > What I did is to implement #isUsed like this in e.g the hierarchy
> > > of RBLintRule:
> > > 
> > > isUsed
> > >   "all my sublasses are used"
> > >   ^self name ~= ‘RBLintRule'
> > > 
> > > this way if RBLintRule is not used, it is seen by the Critique,
> > > but all subclasses
> > > are used by default.
> > > 
> > > I implemented that in TestCase, too, and removed the explicit
> > > check for TestCase
> > > subclasses from the rule.
> > 
> > This is a nice thing. In the same way we can deal with abstract
> > classes. So if someone develops an abstract class with an intent to
> > use it, he can specify that it’s ok to use the class.
> > 
> 
> True.
> > Also is there any work on pragmas for classes, at some point I’ve
> > heard something about it but can’t recall.
> > 
> Yes, the question is where to put it syntactically

After a class declaration like this: 

LLVMDisposableObject subclass:#LLVMDIBuilder
instanceVariableNames:''
classVariableNames:''
poolDictionaries:'LLVMModuleFlagBehavior'
category:'LLVM-S-Core'

Annotation key: 'disposable:' value: 'true'

This ANSI-compatible way (see page 39 of NCITS J20 DRAFT
of ANSI Smalltalk Standard, rev 1.9). 

Perhaps nice way is 

Annotation disposable: true


>  and how to save it in monticello… 

In the source as above. In the binary, in a separate
entry in the .zip so the other MC implementation won't 
crash but silently ignore them. 

Re: [Pharo-dev] ANSICompatibility package

[Jan Vrany]

> > I would rename it to SmalltalkCompatibility to ANSICompatibility
> > because
> > "Compatibility" is a too general term and could mean backward
> > compatibility
> > of Pharo versions or compatibility to other languages as well.
> 
> That was me :)  I was thinking more broadly that over time the
> "repository" might  hold different packages Compatibility-ANSI,
> Compatibility-VW, Compatibility-Dolphin.  But maybe that is
> overreaching and its better to be more focussed. Let me know what you
> think on this and restate what you think the repository name should
> be.

Ben, could you please give me a commit access? I intend to
move Compatibility-SmalltalkX and Compatibility-ANSI (which
I created and "maintain" for my own need). Maybe some others
may find them useful or maybe even contribute. 

Cheers, Jan

> 
> > Also see http://wiki.squeak.org/squeak/2384 and 
> > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d3389ec
> > which could be a start.
> 
> I saw those, but they interact with existing classes, so I thought it
> easier to kickstart by loading in the tests first, which are all new
> classes.  I only created the repository since the tests were *hard*
> to
> find eventually at
> http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compatibili
> ty/
> So I thought it would be good make them more accessible as a
> Monticello Package.
> 
> cheers -ben
> 
> P.S. I don't quite follow "to SmalltalkCompatibility to
> ANSICompatibility"
> do you mean "to SmalltalkCompatibility or ANSICompatibility" ?
> 
> > 
> > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr
> > > Von: stepharo 
> > > An: "Pharo Development List" 
> > > Betreff: Re: [Pharo-dev] ANSICompatibility package
> > > 
> > > We should have a SmalltalkCompatibility (not Ansi per se) package
> > > were we can add some methods to help migration.
> > > 
> > > Stef
> > > 
> > > 
> > > Le 8/9/15 06:04, Ben Coman a écrit :
> > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <
> > > > jan.vr...@fit.cvut.cz> wrote:
> > > > > Hi,
> > > > > 
> > > > > is there actually such a thing like ANSICompatibility
> > > > > package?
> > > > > (it has been mentioned here lately, but I cannot find it)
> > > > > 
> > > > > Thanks, Jan
> > > > > 
> > > > I made it up for the purpose of discussion to see what interest
> > > > it generated.
> > > > Should we start one ?
> > > > cheers -ben
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > 
> 
> 

Re: [Pharo-dev] ANSICompatibility package

[Jan Vrany]

On Wed, 2015-09-09 at 10:31 +0200, Torsten Bergmann wrote:
> Whoever created 
> http://smalltalkhub.com/#!/~PharoExtras/Compatibility/
> 
> I would rename it to SmalltalkCompatibility to ANSICompatibility 
> because 
> "Compatibility" is a too general term and could mean backward 
> compatibility
> of Pharo versions or compatibility to other languages as well.

+1 to ANSICompatibility

> 
> Also see http://wiki.squeak.org/squeak/2384 and 
> http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d3389ec
> which could be a start.
> 
> 
> > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr
> > Von: stepharo 
> > An: "Pharo Development List" 
> > Betreff: Re: [Pharo-dev] ANSICompatibility package
> > 
> > We should have a SmalltalkCompatibility (not Ansi per se) package
> > were we can add some methods to help migration.
> > 
> > Stef
> > 
> > 
> > Le 8/9/15 06:04, Ben Coman a écrit :
> > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany  
> > > wrote:
> > > > Hi,
> > > > 
> > > > is there actually such a thing like ANSICompatibility package?
> > > > (it has been mentioned here lately, but I cannot find it)
> > > > 
> > > > Thanks, Jan
> > > > 
> > > I made it up for the purpose of discussion to see what interest 
> > > it generated.
> > > Should we start one ?
> > > cheers -ben
> > > 
> > > 
> > 
> > 
> > 
> 
> 

Re: [Pharo-dev] ANSICompatibility package

[Jan Vrany]

Hi, 

On Tue, 2015-09-08 at 12:04 +0200, H. Hirzel wrote:
> Jan,
> 
> have a look at
> 
> http://wiki.squeak.org/squeak/3172
> 
> ca 2800 tests

Thanks for this, I'll make a note...

> 
> First thing to do would be to do an quick analysis of the porting 
> effort.
> 
> The question is why do not need a ANSI compatibility package.
> 
> Grease
> http://www.smalltalkhub.com/#!/~Seaside/Grease11
> is also an issue to look into for creating portable code.
> 
Well:

"Grease enhances the ANSI Smalltalk standard. With only a few
exceptions, we assume platforms are fully ANSI-compliant."

So on Pharo, Grease would not help as, IIUC, Pharo is not and
does now want to be, ANSI compliant. This means that 
ANSICompatibility is (will be) needed for Grease if Pharo keeps
removing ANSI methods, right?

> In the end the incompatible methods in Pharo are often not all that 
> many.
> This means that  what you mention as 'quick and dirty' is actually
> quite a  good approach: You test the Smalltalk platform you are using
> for the availability of certain methods and act accordingly.

Except it makes the code a lot less comprehensible...
Anyway, problem solved :-)

Jan
> 
> 
> --Hannes
> 
> On 9/8/15, Jan Vrany  wrote:
> > On Tue, 2015-09-08 at 12:04 +0800, Ben Coman wrote:
> > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany 
> > > wrote:
> > > > Hi,
> > > > 
> > > > is there actually such a thing like ANSICompatibility package?
> > > > (it has been mentioned here lately, but I cannot find it)
> > > > 
> > > > Thanks, Jan
> > > > 
> > > 
> > > I made it up for the purpose of discussion to see what interest 
> > > it
> > > generated.
> > > Should we start one ?
> > 
> > Well, let's put it this way: if there would be one, I'd use it and 
> > even
> > contribute adding missing stuff. But I certainly have no time to 
> > start
> > yet another project, having way too much on my plate already.
> > 
> > So `(passes respondsTo: #removeAtIndex:) ifTrue:[...]` would do it.
> > Quick and dirty, but no time and desire to fight Pharo :-)
> > 
> > Cheers, Jan
> > 
> > > cheers -ben
> > > 
> > 
> > 
> 

Re: [Pharo-dev] ANSICompatibility package

[Jan Vrany]

On Tue, 2015-09-08 at 12:04 +0800, Ben Coman wrote:
> On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany  
> wrote:
> > Hi,
> > 
> > is there actually such a thing like ANSICompatibility package?
> > (it has been mentioned here lately, but I cannot find it)
> > 
> > Thanks, Jan
> > 
> 
> I made it up for the purpose of discussion to see what interest it 
> generated.
> Should we start one ?

Well, let's put it this way: if there would be one, I'd use it and even
contribute adding missing stuff. But I certainly have no time to start
yet another project, having way too much on my plate already. 

So `(passes respondsTo: #removeAtIndex:) ifTrue:[...]` would do it. 
Quick and dirty, but no time and desire to fight Pharo :-)

Cheers, Jan

> cheers -ben
> 

[Pharo-dev] ANSICompatibility package

[Jan Vrany]

Hi, 

is there actually such a thing like ANSICompatibility package?
(it has been mentioned here lately, but I cannot find it)

Thanks, Jan

Re: [Pharo-dev] Need a decision on subString: vs substring:

[Jan Vrany]

...
> > The corollary being, if you make it simple for people to continue
> > maintaining the old dialect, you are more likely to get code ported 
> > to
> > your dialect.
> 
> I agree with that.
> To be compatible with these goals, I think my proposition just needs 
> to be updated a bit.
> I'm still in favor of rules to transform ANSI code to Pharo code. The 
> point is that we should not force the user to update their code base. 
> The rule-cased approach is compatible with that if you transform ANSI 
> 
> code when it gets loaded in the image.

No, it's not! Rewriting the code in this case is actually a very bad 
thing. The problem is that when you port changes done in, say, 
Pharo back to, say, "The other cool Smalltalk" you have rewrite
everything back (or things will break). This is not what you want
to spend you time on. 

So either don't enforce code rewriting in this case or be honest and
say openly "I do not care, not my problem" :-) 

And no, I'm not theorizing, I'm talking out of my 
every-two-weeks-or=-so-pain I'm suffering last year or so. 

Best, Jan

Re: [Pharo-dev] PetitParser speed and cost of PPFailure

[Jan Vrany]

Hi Holger, 

Jan and me are working on a PetitCompiler [1,2], a tool whose aim
is to compile PetitParsers to Smalltalk to gain performance and 
allow for hand-tuning. In short, we try to generate a tokenizer
and LL(1) parser on top of it. In general case, given the flexibility
of PetitParser, this is rather tricky :-) 

The results are - performance wise - not bad, IMO [3].
As long as your grammar is sort of LL(1) it should not backtrack
(but Jan would give you more details, this is his domain)

Now, the whole thing is work-in-progress and by no means
is - as of today - production-ready tool. I'd like to give it
a try and benchmark it as it would make nice case-study for us.
But - no promises time-wise. I'm bloody busy now and this is 
a sort of spare time-project for me.

Best, Jan 

[1] https://bitbucket.org/janvrany/stx-goodies-petitparser
[2] http://smalltalkhub.com/#!/~JanKurs/PetitParser/
[3] http://bit.ly/1IXnz0c 


On Sun, 2015-08-16 at 17:58 +0200, Holger Freyther wrote:
> Hi,
> 
> once again I am not sure if this is the right list. The first parser 
> I wrote using
> PetitParser was a SIP (and then MGCP) parser. I have recently 
> ported[1] the
> code to Pharo and with Pharo it is very tempting to Use 
> BlockClosure>>#bench
> to get an idea of the speed.
> 
> 
> I have two performance “issues” and wonder if others hand similar 
> issues with
> PetitParser and if there is a general approach to this.
> 
> 
> 
> 1.) Combining two PPCharsetPredicates does not combine the 
> “classification”
> table it had. One could create a PPPredicateObjectParser subclass 
> that is
> special casing >>#/ to build a combined classification table.
> 
> 
> 2.) When blindly following a BNF enumeration of "A or B or C or D or 
> E
> or CatchAll” and each “A, B” follow common pattern (e.g. token COLON 
> value)
> one pays a high cost in the backtracking and constructing the 
> PPFailure for
> each failed case.
> 
> In my SIPGrammar I have action parsers for To ==>.. From ==>  and 
> would
> like to keep that. At the same time I would be happy if the token in 
> front of the
> colon is only consumed once and then delegated to the right parser 
> and if that
> one failed use the ‘catch all’ one.
> 
> I don’t know which abstraction would be needed to allow creating 
> optimized
> PetitParsers for such grammars.
> 
> sorry for the long mail, long details and context is below.
> 
> 
> kind regards
>   holger
> 
> 
> 
> 
> 
> 
> Full details:
> 
> 
> 1.) CharSetPredicate
> 
> > aParser bParser combinedParser aTime bTime cTime |
> 
> aParser := #digit asParser.
> bParser := #letter asParser.
> combinedParser := aParser / bParser.
> 
> aTime := [  aParser parse: 'b'] bench.
> bTime := [ bParser parse: 'b'] bench.
> cTime := [ combinedParser parse: 'b'] bench.
> { aTime. bTime. cTime }
> 
> cTime is bounded by the time execution time of of the slowest
> of these parsers + overhead (e.g. PPFailure creation).
> 
> e.g.
> 
> #('559,000 per second.' '1,010,000 per second.' '429,000 per 
> second.')
> 
> With a proof of concept PPPredicateCharSetParser
> 
> #('1,330,000 per second.' '1,550,000 per second.' '1,580,000 per 
> second.’)
> 
> The noise is pretty string here but what is important is that bParser 
> and the
> combinedParser are in the same ballpark.
> 
> 2.) Choice Parser
> 
> 
> 
> The BNF grammar of the parser is roughly:
> 
> Request=  Request-Line
>   *( message-header )
>   CRLF
>   [ message-body ]
> 
> message-header  =  (Accept
>   …
>   / To 
>   / From
>   / Via
>   /  extension-header) CRLF
> 
> Alert-Info   =  "Alert-Info" HCOLON alert-param *(COMMA alert-param)
> Accept =  "Accept" HCOLON
>[ accept-range *(COMMA accept-range) ]
> 
> 
> So there can be several lines of “message-header”. And each method 
> header
> starts with a token/word, a colon and then the parameter. “extension
> -header”
> is kind of a catch all if no other rule matched. E.g. if a client 
> sends a To which is
> wrongly encoded it would end up with the extension-header.
> 
> I transferred the above naively to PetitParser and end up with 
> something like
> parsing ~500 messages a second. The main cost appears to come from 
> the
> choice parser that needs to create a PetitFailure all the time. E.g. 
> if you have a
> line like this:
> 
>   ‘From: “Holger Freyther” ’
> 
> The choice parser will start with the “Accept” rule, parse the token 
> (“From” and
> then create a PPFailure, then … rules, then “To”, parse the token.. 
> So we have
> parsing the same token more than once and creating PPFailures all the 
> time. I
> ended up creating a custom parser that will peek the token, have a 
> horrible chain
> of token = ‘XYZ’ ifTrue and then dispatch to the other rule.
> 
> It would be nice if PetitParser could be taught to only parse the 
> token once and
> then delegate to the param rule. E.g.

Re: [Pharo-dev] Multiple syntax support in Pharo

[Jan Vrany]

Hi Clement, 

I have done exactly this a long time ago. I went even further, 
allowing different methods being written in different languages
(so one could have a class with one method in Smalltalk, other in 
Java, third in JavaScript, fourth in Ruby or even LISP)

Now, fiddling with parser/compiler was actually the easiest part. 
The hard (though not "difficult") part was to make it working so
one can commit and load back the package smoothly, senders /
implementors work as expected, debugger is not confused, inspector
still works and uses the right compiler for the object, changes
are written properly and could be actually loaded back. Myriads of
little details...

And yes, as soon as "the other language" semantics differ from
Smalltalk, you expose yourself to a number of interoperability issues,
depending how much different it is. Some of these problems are easy,
some of them tricky. Most of them tricky :-) So better stick to
Smalltalk semantics...

And what is the worst :-) even if you manage to make it up and running,
then only to find out that "ordinary" programmers don't like it. 
They want only one language to rule them all. How many times I have
heard "I don't like programming in this or that, I want program
everything in Smalltalk (substitute for your favorite)". So, be 
prepared.

If you'd still give it a go, I'd be happy to discuss details.

My 2 cents. 

Jan




On Tue, 2015-08-04 at 10:08 +0200, Clément Bera wrote:
> Hello Pharoers,
> 
> I'd like to do something a bit crazy and I think it's possible in 
> Pharo so I'm asking for advises here.
> 
> I would like to have packages / hierarchy of classes in Pharo that 
> have methods written with a different syntax.
> 
> I know that syntax coloring and most refactoring tools work on AST. 
> So is it possible, for a given class, to override #parser or 
> #parserClass class side in a similar way that you can override 
> #compiler and #compilerClass, and from then on, the class methods 
> will use this parser instead of RBParser to be parse its methods 
> source code to the AST in the compilation chain and for syntax 
> coloring (hence with full compatibility with the class browser) ?
> 
> I am talking about another syntax that would be parsed to the same 
> AST for now, though as the compiler can be changed too, I guess a 
> complete separate compilation chain and AST could work fine if the 
> AST has common APIs with RB for the refactoring browser and syntax 
> coloring.
> 
> What do you think ?

Re: [Pharo-dev] Disabling Rubric in Nautilus (+VM crash)

[Jan Vrany]

Hi. 
...

> > FFI calls except those done by system as shipped. So in the end
> > something else seems to be broken and Rubric performance could be
> > just a consequence. Maybe I suspected the wrong guy. Sorry about 
> > that.
> Yes and no, the 5.0 Image has a problem with loading FT-Fonts at 
> startup

Likely. Apparently I'm not alone who has this problem. Jan suggested
this could be due to connection/disconnection of an external
monitor. Could be. I'm switching a lot (and always did) between
"office" workplace
(docking station with 2 external LCDs) and "armchair" like workplace
using laptops internal panel. Both me an Jan are using Linux on a very
similar hardware.

Maybe a starting point to chase this down - perhaps image is cacheing
(not invalid) screen id or something like this. GDB could tell :-) 

Best, Jan

Re: [Pharo-dev] Disabling Rubric in Nautilus (+VM crash)

[Jan Vrany]

On Wed, 2015-07-22 at 14:55 +0200, stepharo wrote:
> Jan do you have a scenario where we can see the performance issue?
> 

Hmm...actually not reproducible one. Here's the story: 

It happened me couple times that the CPU (core) usage was 100% when
I typed in Nautilus. When I stopped typing, CPU usage went to 5%
(which is "normal" IIUC). 

I saved the image when it exhibited the performance problem, but the
other day it failed to open at all. VM crashed before opening the
window (log attached if anyone's interested - from the trace it looks
like freetype plugin's doing something wrong. 

Funny enough after not having time for this for couple days,
I tried again and the (i) the image does start and (ii) it does no
longer exhibit the poor performance. 

I'm bloody sure nothing changed in my system meanwhile (no VM change,
no upgrade of system libraries, etc). The image that crashed used no 
FFI calls except those done by system as shipped. So in the end
something else seems to be broken and Rubric performance could be 
just a consequence. Maybe I suspected the wrong guy. Sorry about that.

Best, Jan


> 
> Le 22/7/15 10:03, Jan Vrany a écrit :
> > On Tue, 2015-07-21 at 23:38 +0200, Franck Warlouzet wrote:
> > > Hello Jan,
> > > 
> > > On Pharo 5, I don't think so (unless you want to reload the very 
> > > old
> > > commits from nautilus). PluggableTextMorph will be remove so we 
> > > will
> > > not put an option to switch between Rubric or that.
> > Right. Is there a way to dig out an older image prior the switch?
> > 
> > > What do not you like with Rubric ?
> > It's not that I don't like it, but in my very case it burns
> > my CPU. Looks like a performance problem.
> > 
> > Thanks! Jan
> > 
> > > Franck
> > > 
> > > > From: jan.vr...@fit.cvut.cz
> > > > To: pharo-dev@lists.pharo.org
> > > > Date: Tue, 21 Jul 2015 22:19:05 +0100
> > > > Subject: [Pharo-dev] Disabling Rubric in Nautilus
> > > > 
> > > > Hi there,
> > > > 
> > > > is there a way to disable Rubric in Nautilus and get back
> > > > to PluggableTextMorph or whichever beast was used before?
> > > > Quick search in settings did not help.
> > > > 
> > > > Jan
> > > > 
> > 
> 
> 
Segmentation fault Fri Jul 24 13:15:36 2015


/home/jv/Projects/Pharo/5.0/pharo-vm/pharo
pharo VM version: 3.9-7 #1 Thu Apr  2 00:51:45 CEST 2015 gcc 4.6.3 [Production 
ITHB VM]
Built from: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 
4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  2 2015
With: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 
4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  2 2015
Revision: https://github.com/pharo-project/pharo-vm.git Commit: 
32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: 
Esteban Lorenzano  Jenkins build #14904
Build host: Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 
16:39:45 UTC 2012 i686 i686 i386 GNU/Linux
plugin path: /home/jv/Projects/Pharo/5.0/pharo-vm/ [default: 
/home/jv/Projects/Pharo/5.0/pharo-vm/]


C stack backtrace & registers:
eax 0xffd768a4 ebx 0xffd767c0 ecx 0xffd76858 edx 0xffd7680c
edi 0xffd76690 esi 0xffd76690 ebp 0xffd76728 esp 0xffd76774
eip 0xffd76988
*[0xffd76988]
/home/jv/Projects/Pharo/5.0/pharo-vm/pharo[0x80a33a2]
/home/jv/Projects/Pharo/5.0/pharo-vm/pharo[0x80a3706]
linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xf76febe0]
/usr/lib/i386-linux-gnu/libfreetype.so.6(FT_Stream_ReadULong+0x6e)[0xb6ea540e]
/usr/lib/i386-linux-gnu/libfreetype.so.6(+0x52407)[0xb6ee8407]
/usr/lib/i386-linux-gnu/libfreetype.so.6(+0x23d8a)[0xb6eb9d8a]
/usr/lib/i386-linux-gnu/libfreetype.so.6(+0x10eab)[0xb6ea6eab]
/usr/lib/i386-linux-gnu/libfreetype.so.6(FT_Open_Face+0x2d9)[0xb6ea9bb9]
/usr/lib/i386-linux-gnu/libfreetype.so.6(FT_New_Memory_Face+0x5a)[0xb6eaa1ca]
/home/jv/Projects/Pharo/5.0/pharo-vm/libFT2Plugin.so(primitiveNewMemoryFaceFromExternalMemoryAndIndex+0xfa)[0xf70af13a]
/home/jv/Projects/Pharo/5.0/pharo-vm/pharo[0x80799ca]
/home/jv/Projects/Pharo/5.0/pharo-vm/pharo(interpret+0x234c)[0x809741c]
/home/jv/Projects/Pharo/5.0/pharo-vm/pharo(enterSmalltalkExecutiveImplementation+0x59)[0x809a619]
/home/jv/Projects/Pharo/5.0/pharo-vm/pharo(interpret+0x1ee)[0x80952be]
/home/jv/Projects/Pharo/5.0/pharo-vm/pharo(main+0x2b2)[0x805ba82]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xf3)[0xf74d7a63]
/home/jv/Projects/Pharo/5.0/pharo-vm/pharo[0x805bda1]
/home/jv/Projects/Pharo/5.0/pharo-vm/pharo[0x810c90c]


Smalltalk stack dump:
0xffd84e54 I [] in FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: 
0xb8d8f240: a(n) FreeTypeFace
0xffd84e6c M BlockClosure>on:do: 0xb984f828: a(n

Re: [Pharo-dev] Disabling Rubric in Nautilus

[Jan Vrany]

On Wed, 2015-07-22 at 10:18 +0200, Franck Warlouzet wrote:
> With the latest image the FastTable are disabled by default.
> 
> 
> You can find the older images easily with Pharo Launcher but I do not 
> remember the exact number. Try before 50133 or something like that, 


Great, thanks! This makes binary search easier :-) 

> then you could file out Nautilus package et merge it on your latest 
> image. But I do not know what will happen, maybe there is a little 
> bit more to do.

Older image is fine, but thanks anyway! 

Jan

> 
> Franck
> 
> From: chisvasileand...@gmail.com
> Date: Wed, 22 Jul 2015 10:09:51 +0200
> To: pharo-dev@lists.pharo.org
> Subject: Re: [Pharo-dev] Disabling Rubric in Nautilus
> 
> That performance problem might be due to FastTable.
> Try disabling it: Nautilus useExperimentalFastTable: false
> 
> 
> Andrei
> 
> On Wed, Jul 22, 2015 at 10:03 AM, Jan Vrany  
> wrote:
> On Tue, 2015-07-21 at 23:38 +0200, Franck Warlouzet wrote:
> > Hello Jan,
> >
> > On Pharo 5, I don't think so (unless you want to reload the very 
> old
> > commits from nautilus). PluggableTextMorph will be remove so we 
> will
> > not put an option to switch between Rubric or that.
> 
> Right. Is there a way to dig out an older image prior the switch?
> 
> >
> > What do not you like with Rubric ?
> 
> It's not that I don't like it, but in my very case it burns
> my CPU. Looks like a performance problem.
> 
> Thanks! Jan
> 
> >
> > Franck
> >
> > > From: jan.vr...@fit.cvut.cz
> > > To: pharo-dev@lists.pharo.org
> > > Date: Tue, 21 Jul 2015 22:19:05 +0100
> > > Subject: [Pharo-dev] Disabling Rubric in Nautilus
> > >
> > > Hi there,
> > >
> > > is there a way to disable Rubric in Nautilus and get back
> > > to PluggableTextMorph or whichever beast was used before?
> > > Quick search in settings did not help.
> > >
> > > Jan
> > >
> 
> 

Re: [Pharo-dev] Disabling Rubric in Nautilus

[Jan Vrany]

On Tue, 2015-07-21 at 23:38 +0200, Franck Warlouzet wrote:
> Hello Jan,
> 
> On Pharo 5, I don't think so (unless you want to reload the very old 
> commits from nautilus). PluggableTextMorph will be remove so we will 
> not put an option to switch between Rubric or that.

Right. Is there a way to dig out an older image prior the switch? 

> 
> What do not you like with Rubric ?

It's not that I don't like it, but in my very case it burns
my CPU. Looks like a performance problem. 

Thanks! Jan

> 
> Franck
> 
> > From: jan.vr...@fit.cvut.cz
> > To: pharo-dev@lists.pharo.org
> > Date: Tue, 21 Jul 2015 22:19:05 +0100
> > Subject: [Pharo-dev] Disabling Rubric in Nautilus
> > 
> > Hi there, 
> > 
> > is there a way to disable Rubric in Nautilus and get back
> > to PluggableTextMorph or whichever beast was used before?
> > Quick search in settings did not help.
> > 
> > Jan
> > 

[Pharo-dev] Disabling Rubric in Nautilus

[Jan Vrany]

Hi there, 

is there a way to disable Rubric in Nautilus and get back
to PluggableTextMorph or whichever beast was used before?
Quick search in settings did not help.

Jan

Re: [Pharo-dev] Wrong parent in RBProgramNode after a #copy

[Jan Vrany]

Ah, I'm sorry. Pharo is actually file, i.e., sets parent properly on
copy. I checked source of some methods but it's actually done
in others. 

Sorry for the noise! 

Best, Jan


On Thu, 2015-06-18 at 08:08 +0200, stepharo wrote:
> Hi jan
> 
> to me it looks like a bug.
> 
> Stef
> 
> 
> Le 18/6/15 08:04, Jan Vrany a écrit :
> > Hi,
> >
> > while writing some code transformation code, I found out
> > that in many implementations of RBProgramNode & co. the #copy
> > message makes a sort of deep copy, copying also it's child nodes.
> >
> > However, it does NOT sets it's parent to the copy, so for copied
> > nodes, following does not hold:
> >
> >someNode children anyOne parent == someNode
> >
> > This seems to br wrong to me. In other implementations I can
> > simply use #deepCopy and works fine, but I cannot do this in
> > Pharo because #deepCopy fails. The reason is that in Pharo
> > RBProgramNodes are infested with OpalCompiler stuff which
> > apparently keeps BlockClosures which cannot be deep-copied.
> > The tree I'm trying to copy is obtained using
> > BlockClosure>>sourceNode.
> >
> > Question: Is there a way how to copy the parse tree with parents
> > set properly?
> >
> > If not, I'm inclined to fix #copy so it sets parent node properly
> > If that's not desirable for one reason or another, no problem, I'll
> > do it differently (but not-so-nicely :-)
> >
> > Best, Jan
> >
> >
> >
> >
> >
> 
> 

[Pharo-dev] Wrong parent in RBProgramNode after a #copy

[Jan Vrany]

Hi, 

while writing some code transformation code, I found out
that in many implementations of RBProgramNode & co. the #copy 
message makes a sort of deep copy, copying also it's child nodes. 

However, it does NOT sets it's parent to the copy, so for copied
nodes, following does not hold: 

  someNode children anyOne parent == someNode

This seems to br wrong to me. In other implementations I can 
simply use #deepCopy and works fine, but I cannot do this in 
Pharo because #deepCopy fails. The reason is that in Pharo
RBProgramNodes are infested with OpalCompiler stuff which
apparently keeps BlockClosures which cannot be deep-copied. 
The tree I'm trying to copy is obtained using 
BlockClosure>>sourceNode. 

Question: Is there a way how to copy the parse tree with parents
set properly? 

If not, I'm inclined to fix #copy so it sets parent node properly
If that's not desirable for one reason or another, no problem, I'll 
do it differently (but not-so-nicely :-) 

Best, Jan

Re: [Pharo-dev] block syntax experiments

[Jan Vrany]

On Wed, 2015-06-03 at 03:16 +0200, Peter Uhnák wrote:
> But I would like them to be defined like this: 
> 
> 
> 
> [ inc: x | x + 1 ]. 
> (inc: 3) = 4
> 
> 
> [add: x to: y | x + y ].
> (add: 3 to: 4) = 7.
> 
> 
> What do you think? Is it feasible? 
> 
Francisco, Interesting. Looks handy, too :-) 
But I found the syntax bit confusing as it looks
like that the block is created and never stored. 
Maybe 

add:to:= [:x :y | x + y ]
add: 3 to: 4

I'm not terribly happy with that either, but...

> 
> But you still need to have the block saved in a variable. You cannot
> pollute global namespace with names of parameters within the block,
> not to mention the fact that most blocks in the system have same
> parameter names.

> Now while the idea seems interesting; I cannot imagine how it would
> work in practice. Imagine collection's "do:" method explicitly stating
> the name of the argument, which would force me to name it in such and
> such way which would actually impair the readability.
> I am sure others will have different opinions.
> 

This is handy when one needs to define a method-local function sort of
things.
I do that often using the variable + value:value: syntax but it's ugly
and not intention revealing (unless you're really used to this idiom)

> 
> However if you want to try it out, you should apart from Opal have to
> look also at AST-Core since you are changing syntax.
> 
> 
> Also I am thinking that combination of variable name + named arguments
> could perhaps be done purely with overriding doesNotUnderstand: method
> in BlockClosure and calling value:value: internally. (Or even
> cull:cull:, but form what I've heard that has some dire performance
> issues); this could perhaps even solve my comment about enforced
> naming.
> 

Using a doesNotUnderstand: here would have performance problems. 
(unless Cog does something super-smart)

Jan 
> 
> Peter
> 
> 

Re: [Pharo-dev] Little fix to MC merge facility

[Jan Vrany]

On Tue, 2015-04-21 at 08:41 +0200, Thierry Goubier wrote:
> Le 21/04/2015 07:46, stepharo a écrit :
> >
> >> No, I changed MCMethodDefinition>>= to be more relaxed about
> >> sources and treat two sources that differ only in leading/trailing
> >> spaces as "same". This way, these methods do not occur in merge tool
> >> at all.
> >> This is just a quick fix - much better would be to compare AST's and
> >> treat whitespace-changes specially (i.e., provide a filter to show/hide
> >> whitespace-only-changes).
> >
> > OK now I wonder if we want to have methods with different end of line
> > conventions in the system.
> 
> I pushed a change to MCMethodDefinition>>#= a short while ago because 
> source code was seeing line ending changes...

Could you point me to that? If you don't mind, I'll merge it as it could
help to solve problems I might soon run into :-) 

> 
> AST-based comparison would be nice there; however what about the cost? 
> Some of MC operations are already fairly slow as they are now.

If done on a tool level (where this belongs to IMO) it won't be much of
a problem. Only one might have to wait for window to come up a 
little longer...

> 
> Thierry
> 
> > I do not remember the discussion we got long time ago.
> >
> > Stef
> >>> Do you think that we should integrate it?
> >> Yes.
> >>
> >>> Stef
> >>>
> >>> Le 20/4/15 12:36, Jan Vrany a écrit :
> >>>> Hi,
> >>>>
> >>>> I just wanted to merge some code in Monticello and the merge tool
> >>>> marked all methods as conflict because their source differ in trailing
> >>>> whitespace (newline). The diff panel on the right does not show any
> >>>> difference.
> >>>>
> >>>> http://smalltalkhub.com/#!/~JanVrany/Misc/versions/Monticello-Fixes-JanVrany.1
> >>>>
> >>>>
> >>>> Here's a fix for this particular problem in case somebody runs into the
> >>>> same problem.
> >>>>
> >>>> Best, Jan
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
> 
> 

Re: [Pharo-dev] Little fix to MC merge facility

[Jan Vrany]

On Mon, 2015-04-20 at 20:36 +0300, stepharo wrote:
> Jan
> 
> what is your fix? to show the end of line differently?

No, I changed MCMethodDefinition>>= to be more relaxed about
sources and treat two sources that differ only in leading/trailing
spaces as "same". This way, these methods do not occur in merge tool 
at all. 
This is just a quick fix - much better would be to compare AST's and
treat whitespace-changes specially (i.e., provide a filter to show/hide
whitespace-only-changes). 

> Do you think that we should integrate it?

Yes.

> Stef
> 
> Le 20/4/15 12:36, Jan Vrany a écrit :
> > Hi,
> >
> > I just wanted to merge some code in Monticello and the merge tool
> > marked all methods as conflict because their source differ in trailing
> > whitespace (newline). The diff panel on the right does not show any
> > difference.
> >
> > http://smalltalkhub.com/#!/~JanVrany/Misc/versions/Monticello-Fixes-JanVrany.1
> >
> > Here's a fix for this particular problem in case somebody runs into the
> > same problem.
> >
> > Best, Jan
> >
> >
> >
> 
> 

[Pharo-dev] Bug in SmalltalkHub?

[Jan Vrany]

Hi, 

(Esteban), I'm trying to upload couple .mcz to Smalltalk hub using
following script: 


for f in $(cd mc && ls *.mcz); do  
echo -n "Uploading $f..."
curl --user JanVrany: --upload-file mc/$f
http://smalltalkhub.com/mc/JanVrany/CalipeL-S/main/$f;
echo
done
===

and I'm getting following output: 
===

Uploading
CalipeL-S-Benchmarks-Game-JanVrany.ee1fd4a6e836.20150420125300.mcz...receiver 
of "asTimeStamp" is nil 





   
Uploading
CalipeL-S-Benchmarks-Micro-JanVrany.ee1fd4a6e836.20150420125300.mcz...receiver 
of "asTimeStamp" is nil 





   
Uploading
CalipeL-S-Core-JanVrany.ee1fd4a6e836.20150420125300.mcz...receiver of
"asTimeStamp" is
nil 





   
Uploading
CalipeL-S-Tests-JanVrany.ee1fd4a6e836.20150420125300.mcz...receiver of
"asTimeStamp" is
nil 





   
===

The .mcz load into Pharo image just fine. 
The last time I did this was Dec 2014 and it worked like a charm.
Is it a bug? 
If not, how can I upload a new .mcz to SmalltalkHub? 
I can provide .mczs for debugging. 

Best, Jan

[Pharo-dev] Little fix to MC merge facility

[Jan Vrany]

Hi, 

I just wanted to merge some code in Monticello and the merge tool
marked all methods as conflict because their source differ in trailing
whitespace (newline). The diff panel on the right does not show any 
difference. 

http://smalltalkhub.com/#!/~JanVrany/Misc/versions/Monticello-Fixes-JanVrany.1

Here's a fix for this particular problem in case somebody runs into the
same problem. 

Best, Jan

Re: [Pharo-dev] Switching to Pharo from Visualworks

[Jan Vrany]

On Fri, 2015-02-06 at 10:47 +0100, Markus Fritsche wrote:
> 
> On 06.02.2015 09:33, stepharo wrote:
> 
> > In the coming months we will work on putting in place our
> > bootstrapping kernel.
> > There are no Smalltalk able to do that right now.
> 
> GNU Smalltalk does just that, if it doesn't find an image, it will be
> bootstrapped by using the shipped .st fileouts. 

Smalltalk/X does that too. It does not even need .st fileouts at 
bootstrapping time to come up without an image. 

Jan
> 
> A bit of cheating is involved, a compiler & initialization is
> implemented on the VM side. 
> 
> So I would say "there are no Smalltalk that are able to do that right
> now the way we want to do it" :-P
> 
> (Pissing at the door contest, to refer to another unquoted
> metaphor :-D)

Re: [Pharo-dev] [Pharo-users] CommandLine handler and UTF8 path

[Jan Vrany]

On Tue, 2015-01-20 at 21:35 +0100, Sven Van Caekenberghe wrote:
> Hi Eliot,
> 
> > On 20 Jan 2015, at 20:38, Eliot Miranda  wrote:
> > 
> > 
> > 
> > On Tue, Jan 20, 2015 at 8:00 AM, Sven Van Caekenberghe  wrote:
> > Command line arguments enter the image level via 
> > VirtualMachine>>#getSystemAttribute:
> > 
> > At that point they are already Strings.
> > 
> > ByteString, according to the primitive.  So if the shell supplies e.g. 
> > UTF-8 strings for command-line parameters, which the VM sees as bytes, then 
> > the ByteString instances answered by getSystemAttribute: would need 
> > decoding, right?
> >  
> > In your case, they must already be wrong at that point.
> > 
> > Not necessarily.  The  getSystemAttribute: primitive doesn't do decoding.  
> > Perhaps it should.
> 
> Yes, probably. I just tried on Mac OS X, Pharo 4:
> 
> $ export FOO=élève-Français
> 
> $ echo $FOO
> élève-Français
> 
> $ ./pharo Pharo.image eval 'OSPlatform current environment at: #FOO'
> 'élève-Français'
> 
> $ ./pharo Pharo.image eval '(OSPlatform current environment at: #FOO) 
> asByteArray utf8Decoded'
> 'élève-Français'
> 
> The question is, is this true for all platforms ? Windows ?

Certainly not :-) On UNIX systems the encoding is undefined AFAIK. 
You may want to consult locale before deciding on encoding - 
this works quite well. nl_langinfo() is the guy to ask.

Best, Jan

> 
> > > On 20 Jan 2015, at 16:51, Hilaire  wrote:
> > >
> > > Le 20/01/2015 16:34, Sven Van Caekenberghe a écrit :
> > >> No they are not - Strings and Characters in Pharo are using plain 
> > >> Unicode encoding internally.
> > >
> > > Thanks for the update, and the reference link.
> > >
> > > Hilaire
> > >
> > > --
> > > Dr. Geo - http://drgeo.eu
> > > iStoa - http://istoa.drgeo.eu
> > >
> > >
> > 
> > 
> > 
> > 
> > 
> > -- 
> > best,
> > Eliot
> 
> 
> 

Re: [Pharo-dev] Semaphore seems to timeout prematurely

[Jan Vrany]

On Fri, 2014-12-05 at 20:52 +0800, Ben Coman wrote:
> Jan Vrany wrote:
> > Hi there, 
> > 
> > I have encountered a situation where semaphore timeouts
> > prematurely when run in "non-interactive" mode (eval cmdline handler). 
> > 
> > Setup (script prepare.sh) 
> > 
> > 1) Fresh Pharo image (3.0 / 4.0, both exhibits the same behaviour)
> > 2) Evaluate: 
> > ==
> > Smalltalk at: #WaitBlock put: [:sema :tout | (sema waitTimeoutSeconds:
> > tout) ifTrue:[ Halt now ] ].
> > ==
> > 3. Save image
> > 
> > Run 1: 
> > 1) Run the image, open workspace
> > 2) Evaluate:
> > ==
> > | sema |
> > sema := Semaphore new.
> > [ 100 factorial. sema signal ] fork.
> > (Smalltalk at: #WaitBlock) value: sema value: 60*60.
> > 'OK'
> > ==
> > Returns 'OK' as expected (100 factorial should not take more than
> > hour :-)
> > 
> > 
> > Run 2 (script test.sh)
> > 1) The same, but evaluate using command line handler: 
> > ./pharo Test.image eval "\
> > | sema |\
> > \
> > sema := Semaphore new.\
> > [ 100 factorial. sema signal ] fork.\
> > (Smalltalk at: #WaitBlock) value: sema value: 60*60.\
> > 'OK'\
> > "
> > Halt triggers, which is what I would not expect. 
> > 
> > Why is that? Bug? Or Am I missing something obvious?  
> > 
> > Best, Jan
> 
> Is it like the thread on "Super fast delay" ?
> http://forum.world.st/Super-fast-delay-td4787257.html
> 

Yeah, likely. I don't have enough knowledge of Pharo
internal workings to tell for sure, but like the Delay, 
it does work fine on Windows.

Best, Jan


> I have a fix for Pharo 4 ready to be reviewed...
> https://pharo.fogbugz.com/default.asp?14353
> 
> cheers -ben
> 
> 

[Pharo-dev] Semaphore seems to timeout prematurely

[Jan Vrany]

Hi there, 

I have encountered a situation where semaphore timeouts
prematurely when run in "non-interactive" mode (eval cmdline handler). 

Setup (script prepare.sh) 

1) Fresh Pharo image (3.0 / 4.0, both exhibits the same behaviour)
2) Evaluate: 
==
Smalltalk at: #WaitBlock put: [:sema :tout | (sema waitTimeoutSeconds:
tout) ifTrue:[ Halt now ] ].
==
3. Save image

Run 1: 
1) Run the image, open workspace
2) Evaluate:
==
| sema |
sema := Semaphore new.
[ 100 factorial. sema signal ] fork.
(Smalltalk at: #WaitBlock) value: sema value: 60*60.
'OK'
==
Returns 'OK' as expected (100 factorial should not take more than
hour :-)


Run 2 (script test.sh)
1) The same, but evaluate using command line handler: 
./pharo Test.image eval "\
| sema |\
\
sema := Semaphore new.\
[ 100 factorial. sema signal ] fork.\
(Smalltalk at: #WaitBlock) value: sema value: 60*60.\
'OK'\
"
Halt triggers, which is what I would not expect. 

Why is that? Bug? Or Am I missing something obvious?  

Best, Jan


prepare.sh
Description: application/shellscript


test.sh
Description: application/shellscript

Re: [Pharo-dev] Meaning of VirtualMachine>>incrementalGCCount

[Jan Vrany]

On Thu, 2014-12-04 at 11:43 +0100, Clément Bera wrote:
> Hello Jan,
> 
> 
> An incrementalGC, in the sense of the V3 memory manager, is a scavenge
> (unrelated to what other people call an incremental GC). With the new
> memory manager Spur the names were updated to match common vocabulary.
> 
I thought so :-) but wanted to be sure. Thanks for explanation! 
> 
> Please ask such questions on vm-dev

Right, that would have been better. I'm sorry. 

Best, Jan

> 
> 2014-12-04 10:30 GMT+01:00 Jan Vrany :
> Hi there,
> 
> what's exact meaning of VirtualMachine>>incrementalGCCount?
> Comment says: "Answer the total number of incremental GCs
> since startup
> (read-only)." But what exactly is called 'incremental CG' in
> context of
> PharoVM?
> 
> Again, thanks for any clarification :-)
> 
> Jan
> 
> 
> 
> 
> 
> 

Re: [Pharo-dev] How to tell Pharo 3.0 from 4.0

[Jan Vrany]

On Thu, 2014-12-04 at 10:54 +0100, Sven Van Caekenberghe wrote:
> SystemVersion current

Great, thanks! Jan

[Pharo-dev] Meaning of VirtualMachine>>incrementalGCCount

[Jan Vrany]

Hi there,

what's exact meaning of VirtualMachine>>incrementalGCCount?
Comment says: "Answer the total number of incremental GCs since startup
(read-only)." But what exactly is called 'incremental CG' in context of
PharoVM?

Again, thanks for any clarification :-) 

Jan

[Pharo-dev] How to tell Pharo 3.0 from 4.0

[Jan Vrany]

Hi, 

how do I tell from within a running image whether 
I'm running on Pharo 3.0 or 4.0 image? Thanks! 

Jan

Re: [Pharo-dev] About RBCompiler

[Jan Vrany]

On Sun, 2014-11-23 at 10:13 +0100, Marcus Denker wrote:
> > On 22 Nov 2014, at 18:17, Serge Stinckwich  
> > wrote:
> > 
> > I'm trying to port QuasiQuote package from Lukas Renggli to Pharo 3.0/4.0.
> > This package use the RBCompiler class from the AST-Compiler package
> > available here:
> > http://source.lukas-renggli.ch/helvetia
> > 
> > If I understand RBCompiler, this is a Compiler that use RB parser nodes.
> > I guess this is something that is no more relevant with the new Opal 
> > compiler ?
> > 
> 
> Yes, this is the PetitParser based Smalltalk parser that created RB 
> ParseNodes.
> 
> Opal has a pluggable architecture for the parser, right now it just uses the 
> hand-written
> RB Parser that came with the refactoring browser.
> 
> It would be very nice small experiment to  plug in the Petitparser based one. 
> 
> Especially interesting: Would it be much slower?
Hi Markus, 

Jan Kurs and me are now working on some PetitParser stuff. If we succeed
then PetitParser-based parser would be as fast as current hand-written 
RBParser. We're at the beginning but preliminary benchmarks are very 
promising.  

Error recovery and incremental reparsing are in the queue (if we 
find a time :-) 

>   Marcus
> 
> 
> 

Re: [Pharo-dev] Source code formatting guidelines

[Jan Vrany]

Hi, 

On Thu, 2014-11-20 at 16:47 +0100, Henrik Johansen wrote:
> > On 20 Nov 2014, at 2:39 , Jan Vrany  wrote:
> > 
> > 
> > But as I said, I'm more interested in 'low level' details like I
> > mentioned: 
> > 
> > - encoding of the source string
> >  
> > 
> > Best, Jan
> 
> IIRC, the .bin is the entire source string in Datastream-format, that
> is, is a datatype identifier (either ByteString or WideString),
> followed by the raw bytes/words (which is pure Latin1 if ByteString,
> UTF32-BE(?) for WideString, at least since leadingChar of the standard
> Unicode locale was changed to 0). So writing an encoder/decoder
> strictly for use with MCZ's isn't a very big task. (this is what
> gemstone does)

That's what I do as well, but was not 100% sure about the encoding. 
Thanks! 

> 
> The pure text file (.sources) is only used as a fallback** when
> importing code where the .bin is corrupted/absent, it should either be
> pure latin-1, or UTF-8*.
> 

OK, thanks. I do not use .sources file, only .bin :-) But good to know
it should be UTF8

Thanks! 

> Cheers,
> Henry
> 
> * Not sure if it ended up being solved using a BOM-marker for UTF8 (as in the 
> .cs format), or if a UTF8Encoder is used by default, with a fallback to 
> latin1 if an incorrect utf8 character is encountered. 
> ** Ironically, the string export was bugged up until recently, causing lots 
> of confusion when non-latin1 .mcz exported/imported just fine in 
> Squeak/Pharo, but failed to import elsewhere (where the .bin reading was not 
> implemented)
> 

Re: [Pharo-dev] Source code formatting guidelines

[Jan Vrany]

Hi guys, 

thanks for replies. I read books mentioned by Christophe years ago,
they're worth reading indeed. 

But as I said, I'm more interested in 'low level' details like I
mentioned: 
- tabs/spaces? How many spaces if spaces? 
- encoding of the source string
- trailing newlines
- trailing spaces
- ...

The reason is I'm now working with Jan K. on some stuff and he's
using Pharo while I don't. To exchange code I read his .mcz when
merging his changes and generating .mcz for him when he has to merge 
my stuff. However, Pharo's merge tool apparently does not do a 
really great job when it comes to whitespace changes so the merge 
is difficult and error-prone. 
The idea is to transform the source just before spitting out the .mcz to
minimize these false-diffs when one try to merge. 

Best, Jan



On Wed, 2014-11-19 at 15:19 +0100, Nicolai Hess wrote:
> 2014-11-19 14:55 GMT+01:00 Marcus Denker :
> 
> > On 19 Nov 2014, at 14:47, Peter Uhnák 
> > wrote:
> > 
> > how Pharo source code is formatted
> > One could argue that this is equivalent to the default
> > settings of Pharo formatter.
> 
> Which is not good… e.g. it always adds too many line breaks…
> 
> 
> Marcus
> 
> 
> If we can agree on source code guidelines, we should change the
> default settings of the Pharo formatter accordingly.
> 

[Pharo-dev] Source code formatting guidelines

[Jan Vrany]

Hi guys, 

is there any document I can read on how Pharo source code
is/should be formatted? I mean things like 
- tabs/spaces? How many spaces if spaces? 
- encoding of the source string
- trailing newlines
- trailing spaces
- ...

I don't care much about things like whether there should
be a space after ^, opening [ and so on (because there's
a little I can do about it :-)

Best, Jan

Re: [Pharo-dev] Can anyone provide me with clear, complete, and detailed instructions for loading PetitParser into Pharo 3.0?

[Jan Vrany]

Hi Richard,

On Thu, 2014-10-30 at 10:15 -0700, Richard Sargent wrote:
> kurs.jan wrote
> > Hi All,
> > 
> > Sorry for a late reply, here is the latest status with PetitParser and
> > Pharo (tested on Pharo3):
> > 
> > "Configuration should be loaded like this:"
> > Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser';
> > configurationOf: #PetitParser; load.
> > 
> > "Minimal set of parsers to use petit parser:"
> > ConfigurationOfPetitParser project stableVersion load: 'Core'.
> > ConfigurationOfPetitParser project stableVersion load: 'Tests'.
> > 
> > "All the petit parser suite:"
> > ConfigurationOfPetitParser loadDevelopment.
> > 
> > Please, let me know if you have any issues/requirements.
> 
> Thank you, Jan! That worked perfectly.
> 
> I did notice a large number of warnings and errors in the Transcript. Many
> of them we resolved later in the loading, just being load order
> dependencies. But many of them appear to be genuine errors. Are they
> expected?

By coincidence, we're working with Jan on some new PetitParser stuff 
and I bumped into this too and already complained about this 
(privately). So yes, this i known bug. 

It will be fixed soonish, I believe in a week or two, as this 
is a show stopper for me (our compiler does not allow undeclared
variables).

Best, (other) Jan

> 
> The following is a distillation of the messages in the Transcript showing
> these issues. Quite a number of them were resolved; I have annotated them
> with "***Resolved by later load***" at the end of the line.
> 
> 
> PPMemento>>position: (position is Undeclared) 
> PPMemento>>position (position is Undeclared) 
> PPMemoizedParser>>reset: (stream is Undeclared) 
> PPMemoizedParser>>parseOn: (stream is Undeclared) 
> PPMemoizedParser>>parseOn: (stream is Undeclared) 
> PPMemoizedParser>>parseOn: (stream is Undeclared) 
> PPMemoizedParser>>parseOn: (stream is Undeclared) 
> PPMemoizedParser>>parseOn: (stream is Undeclared) 
> PPMemoizedParser>>parseOn: (stream is Undeclared) 
> PPMemoizedParser>>parseOn: (stream is Undeclared) 
> PPMemoizedParser>>parseOn: (stream is Undeclared) 
> PPMemoizedParser>>parseOn: (stream is Undeclared) 
> JavaParserTest>>createContext:(context is shadowed)
> PPMemoizingIslandTest>>testMemo(context is shadowed)
> PPSmalltalkParser>>buildMethod:(pragma is shadowed)
>   Loaded -> PetitParser-JanKurs.253 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ --- cache
> 
> GLMBrowser>>close (GLMBrowserClosed is Undeclared) ***Resolved by later
> load***
> GLMCompositePresentation>>accumulator (GLMAccumulator is Undeclared)
> ***Resolved by later load***
> GLMCompositePresentation>>actionList (GLMActionListPresentation is
> Undeclared) ***Resolved by later load***
> GLMCompositePresentation>>diff (GLMDiffPresentation is Undeclared)
> ***Resolved by later load***
> GLMCompositePresentation>>dropDownList (GLMDropDownListPresentation is
> Undeclared) ***Resolved by later load***
> GLMCompositePresentation>>dynamic (GLMDynamicPresentation is Undeclared)
> ***Resolved by later load***
> GLMCompositePresentation>>finder (GLMFinder is Undeclared) ***Resolved by
> later load***
> GLMCompositePresentation>>list (GLMListPresentation is Undeclared)
> ***Resolved by later load***
> GLMCompositePresentation>>morph (GLMMorphPresentation is Undeclared)
> ***Resolved by later load***
> GLMCompositePresentation>>smalltalkCode (GLMSmalltalkCodePresentation is
> Undeclared) ***Resolved by later load***
> GLMCompositePresentation>>spec (GLMSpecPresentation is Undeclared)
> ***Resolved by later load***
> GLMCompositePresentation>>table (GLMTablePresentation is Undeclared)
> ***Resolved by later load***
> GLMCompositePresentation>>tabulator (GLMTabulator is Undeclared) ***Resolved
> by later load***
> GLMCompositePresentation>>text (GLMTextPresentation is Undeclared)
> ***Resolved by later load***
> GLMCompositePresentation>>tree (GLMTreePresentation is Undeclared)
> ***Resolved by later load***
> GLMCompositePresentation>>wrapper (GLMWrapper is Undeclared) ***Resolved by
> later load***
> GLMPresentation>>windowIsClosing (GLMBrowserClosing is Undeclared)
> ***Resolved by later load***
>   Loaded -> Glamour-Core-TudorGirba.285 ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/ --- cache
> 
> GLMSmalltalkCodePresentation>>defaultSelectionActions (GLMUIThemeExtraIcons
> is Undeclared) ***Resolved by later load***
> GLMSmalltalkCodePresentation>>defaultSelectionActions (GLMUIThemeExtraIcons
> is Undeclared) ***Resolved by later load***
>   Loaded -> Glamour-Presentations-TudorGirba.165 ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/ --- cache
> 
> GLMExamplesBrowser>>exampleIn: (GLMUIThemeExtraIcons is Undeclared)
> ***Resolved by later load***
> GLMBasicExamples>>browserWithToolbar (GLMUIThemeExtraIcons is Undeclared)
> ***Resolved by later load***
> GLMBasicExamples>>morphIcons (GLMUIThemeExtraIcons is Undeclared)
> ***Resolved by later load***
> GLMBasicExamples>>multipleActions (GLM

Re: [Pharo-dev] Selecting only rules for checking methods

[Jan Vrany]

I tell them apart by looking at their #resultClass. 
HTH, Jan

On Mon, 2014-10-13 at 17:30 +0200, Yuriy Tymchuk wrote:
> Hi,
> 
> In Smalllint the basic rule has two methods: #checkClass: and #checkMethod:.
> 
> They do nothing, and the idea is that every rule is used to check both 
> classes and methods, but only ones that redefine #checkClass: or 
> #checkMethod: actually do something. This is fine, but I wonder if it is 
> possible, to tell about the rule whether it checks method or not. Just 
> checking is it local defines #checkMethod: doesn’t work, as some rules define 
> #checkMethod: and then their subclasses override other methods. One idea that 
> I had is to get the CompiledMethod object of RBBasicLintRule and check if it 
> is different from the one used in current class. But maybe there is a better 
> way?
> 
> Uko
> 

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

[Jan Vrany]

OK.

I think enough has been said. No need to waste more time on it. 
I closed the issue. 
Thanks Nicolai for making the slice for me!

Best, Jan


On Sat, 2014-10-04 at 21:14 +0100, Jan Vrany wrote:
> Hi guys, 
> 
> I've just opened:
> 
> https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-methods-to-SmalltalkImage-to-ease-cross-dialect-development
> 
> Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to
> SmalltalkImage to ease multi-dialect development. 
> 
> RATIONALE:
> 
> Commonly used approach to solve differences among dialect is to use a
> sort of platform object and dispatch there for troublesome operations
> that has to be specialized. This platform object is usually in platform
> specific package. 
> Other option is to load some library like Grease or Sport. 
> 
> The problem of the first approach is that brings to much (unnecessary)
> burden when used for two, three things. The amount of of the code and
> management is way to bigger then the amount of the code that has to be
> specialized. Loading Grease/Sport on the other hand introduces a
> dependency on an external package - not worth of for two or three
> things. 
> 
> The proposed dialect testing messages would allow for simple,
> #ifdef-like idiom like:
> 
> | stream |
> ...
> ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk
> isSomeCoolDialect]) ifTrue:[
>   stream := CharacterWriteStream on: (String new: 10)
> ] ifFalse:[
>   stream := WriteStream on: (String new: 10)
> ]
> 
> The #respondsTo: check, while not nice, is required as at the moment not
> all dialects could be trusted to have these testing messages.
> 
> Putting these methods may not stick with Pharo standard (whatever it
> is), but Smalltalk global is probably one of the
> very few that are present in pretty much every Smalltalk implementation.
> Other option would be to place them to the class side of an Object
> (which is amost certainly present everywhere), however
> 
> Smalltalk isPharo
> 
> reads better than
> 
> Object isPharo.
> 
> Best, Jan
> 
> 

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

[Jan Vrany]

On Sun, 2014-10-05 at 19:08 -0700, Paul DeBruicker wrote:
> Would using Metacello's knowledge of the platform work for you?  e.g.
> 
> 
> (MetacelloPlatform current defaultPlatformAttributes includes: '#squeak')
> ifTrue:[ ... ] 
> (MetacelloPlatform current defaultPlatformAttributes includes: '#pharo1.2') 
> .
> (MetacelloPlatform current defaultPlatformAttributes includes:
> '#gemstone2.4')  .

Actually not. Dependency on Metacello is not what I want. Metacello is is not 
maintained on GST or VAST, after all. 

> 
> Or are you trying to get very very cross platform (e.g. GST, VAST, etc...) ? 

Yes.

Just to make myself clear, I did not proposed this to solve some problem I'm 
facing now. It's just that this very simple idiom has proved itself over years, 
and 
almost certainly cannot break anything, so I decided to contribute. 

Jan
> 
> 
> 
> Jan Vrany wrote
> > On Sun, 2014-10-05 at 10:29 +0200, Johan Brichau wrote:
> >> It’s true that when you do a lot of cross-dialect development, such a
> >> method is often what you desire.
> >> However, I think it’s better to do feature detection instead of dialect
> >> detection. So, something like:
> >> 
> >> ((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[
> >>   stream := CharacterWriteStream on: (String new: 10)
> >> ] ifFalse:[
> >>   stream := WriteStream on: (String new: 10)
> >> ]
> >>
> > 
> > Right, in this example it could eventually work. Another concrete
> > example I bumped just yesterday. The "feature testing" code would look
> > like 
> > 
> > ((Character respondsTo: #to:) and:[($a to: $z) isKindOf: Interval])
> > ifTrue:[
> >...
> > ] ifFalse:[
> >...
> > ].
> > 
> > (true, in this very case you may be able to get around using different
> > method, but you get the point, no?)
> > 
> > Some time ago Hilaire posted a very nice, 15 lines long code that does
> > reliable "feature detection" whether the system is Pharo 2.0 or 3.0 
> > (or similar, I don't remember exactly). 
> > 
> > Is the interval testing code above more robust? Perhaps. Is it more
> > readable, more intention revelaling? I doubt it. 
> > 
> > While I can agree that feature testing is is better, however, in my
> > experience it is very tricky if the code does not provide support for
> > such tests. 
> > 
> >> And yes: use Grease where applicable. We try to maintain Grease across
> >> Pharo, Squeak and Gemstone. I also think it’s actively ported to VA.
> >> 
> > That's great. But having such dependency is exactly what I, and not only
> > me, don't want if it would be for only one or two methods. The aim is to
> > provide a simple solution for simple cases, not a silver bullet.
> > 
> > Jan  
> > 
> > 
> >> cheers
> >> Johan
> >> 
> >> On 05 Oct 2014, at 09:00, stepharo <
> 
> > stepharo@
> 
> > > wrote:
> >> 
> >> > Hi jan
> >> > 
> >> > Thanks for the proposal.
> >> > I thought about it and I'm against because it goes again the idea of
> >> dispatch.
> >> > I prefer to have a class and some dispatch. Seaside with Grease is the
> >> way to go from my perspective.
> >> > Finally I do not want such methods in the systems because I spent my
> >> time removing is because of bad design.
> >> > Let us see what other people think.
> >> > 
> >> > Stef
> >> > 
> >> > On 4/10/14 22:14, Jan Vrany wrote:
> >> >> Hi guys,
> >> >> 
> >> >> I've just opened:
> >> >> 
> >> >>
> >> https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-methods-to-SmalltalkImage-to-ease-cross-dialect-development
> >> >> 
> >> >> Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods
> >> to
> >> >> SmalltalkImage to ease multi-dialect development.
> >> >> 
> >> >> RATIONALE:
> >> >> 
> >> >> Commonly used approach to solve differences among dialect is to use a
> >> >> sort of platform object and dispatch there for troublesome operations
> >> >> that has to be specialized. This platform object is usually in
> >> platform
> >> >> specific package.
> >> >> Other option is to load some library like Grease or Sport.
&g

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

[Jan Vrany]

On Sun, 2014-10-05 at 10:29 +0200, Johan Brichau wrote:
> It’s true that when you do a lot of cross-dialect development, such a method 
> is often what you desire.
> However, I think it’s better to do feature detection instead of dialect 
> detection. So, something like:
> 
> ((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[
>   stream := CharacterWriteStream on: (String new: 10)
> ] ifFalse:[
>   stream := WriteStream on: (String new: 10)
> ]
>

Right, in this example it could eventually work. Another concrete
example I bumped just yesterday. The "feature testing" code would look
like 

((Character respondsTo: #to:) and:[($a to: $z) isKindOf: Interval])
ifTrue:[
   ...
] ifFalse:[
   ...
].

(true, in this very case you may be able to get around using different
method, but you get the point, no?)

Some time ago Hilaire posted a very nice, 15 lines long code that does
reliable "feature detection" whether the system is Pharo 2.0 or 3.0 
(or similar, I don't remember exactly). 

Is the interval testing code above more robust? Perhaps. Is it more
readable, more intention revelaling? I doubt it. 

While I can agree that feature testing is is better, however, in my
experience it is very tricky if the code does not provide support for
such tests. 

> And yes: use Grease where applicable. We try to maintain Grease across Pharo, 
> Squeak and Gemstone. I also think it’s actively ported to VA.
> 
That's great. But having such dependency is exactly what I, and not only
me, don't want if it would be for only one or two methods. The aim is to
provide a simple solution for simple cases, not a silver bullet.

Jan  


> cheers
> Johan
> 
> On 05 Oct 2014, at 09:00, stepharo  wrote:
> 
> > Hi jan
> > 
> > Thanks for the proposal.
> > I thought about it and I'm against because it goes again the idea of 
> > dispatch.
> > I prefer to have a class and some dispatch. Seaside with Grease is the way 
> > to go from my perspective.
> > Finally I do not want such methods in the systems because I spent my time 
> > removing is because of bad design.
> > Let us see what other people think.
> > 
> > Stef
> > 
> > On 4/10/14 22:14, Jan Vrany wrote:
> >> Hi guys,
> >> 
> >> I've just opened:
> >> 
> >> https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-methods-to-SmalltalkImage-to-ease-cross-dialect-development
> >> 
> >> Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to
> >> SmalltalkImage to ease multi-dialect development.
> >> 
> >> RATIONALE:
> >> 
> >> Commonly used approach to solve differences among dialect is to use a
> >> sort of platform object and dispatch there for troublesome operations
> >> that has to be specialized. This platform object is usually in platform
> >> specific package.
> >> Other option is to load some library like Grease or Sport.
> >> 
> >> The problem of the first approach is that brings to much (unnecessary)
> >> burden when used for two, three things. The amount of of the code and
> >> management is way to bigger then the amount of the code that has to be
> >> specialized. Loading Grease/Sport on the other hand introduces a
> >> dependency on an external package - not worth of for two or three
> >> things.
> >> 
> >> The proposed dialect testing messages would allow for simple,
> >> #ifdef-like idiom like:
> >> 
> >> | stream |
> >> ...
> >> ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk
> >> isSomeCoolDialect]) ifTrue:[
> >>   stream := CharacterWriteStream on: (String new: 10)
> >> ] ifFalse:[
> >>   stream := WriteStream on: (String new: 10)
> >> ]
> >> 
> >> The #respondsTo: check, while not nice, is required as at the moment not
> >> all dialects could be trusted to have these testing messages.
> >> 
> >> Putting these methods may not stick with Pharo standard (whatever it
> >> is), but Smalltalk global is probably one of the
> >> very few that are present in pretty much every Smalltalk implementation.
> >> Other option would be to place them to the class side of an Object
> >> (which is amost certainly present everywhere), however
> >> 
> >> Smalltalk isPharo
> >> 
> >> reads better than
> >> 
> >> Object isPharo.
> >> 
> >> Best, Jan
> >> 
> >> 
> >> 
> > 
> > 
> 
> 
> 

[Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

[Jan Vrany]

Hi guys, 

I've just opened:

https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-methods-to-SmalltalkImage-to-ease-cross-dialect-development

Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to
SmalltalkImage to ease multi-dialect development. 

RATIONALE:

Commonly used approach to solve differences among dialect is to use a
sort of platform object and dispatch there for troublesome operations
that has to be specialized. This platform object is usually in platform
specific package. 
Other option is to load some library like Grease or Sport. 

The problem of the first approach is that brings to much (unnecessary)
burden when used for two, three things. The amount of of the code and
management is way to bigger then the amount of the code that has to be
specialized. Loading Grease/Sport on the other hand introduces a
dependency on an external package - not worth of for two or three
things. 

The proposed dialect testing messages would allow for simple,
#ifdef-like idiom like:

| stream |
...
((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk
isSomeCoolDialect]) ifTrue:[
  stream := CharacterWriteStream on: (String new: 10)
] ifFalse:[
  stream := WriteStream on: (String new: 10)
]

The #respondsTo: check, while not nice, is required as at the moment not
all dialects could be trusted to have these testing messages.

Putting these methods may not stick with Pharo standard (whatever it
is), but Smalltalk global is probably one of the
very few that are present in pretty much every Smalltalk implementation.
Other option would be to place them to the class side of an Object
(which is amost certainly present everywhere), however

Smalltalk isPharo

reads better than

Object isPharo.

Best, Jan

Re: [Pharo-dev] ANN - Pre-compiled Pharo VM for Debian Stable

[Jan Vrany]

On Mon, 2014-09-29 at 14:40 +0200, Damien Cassou wrote:
> On Mon, Sep 29, 2014 at 12:17 AM, Jan Vrany  wrote:
> > Getting Pharo 2.0/3.0 up and running on Debian Wheezy (= Stable) or on
> > other more conservative linux distribution wasn't exactly easy as the
> > VM's provided by the Pharo team fail to run on those systems.
> 
> 
> what about putting your work on files.pharo.org
> 
I don't mind.

[Pharo-dev] ANN - Pre-compiled Pharo VM for Debian Stable

[Jan Vrany]

Hi there,

Getting Pharo 2.0/3.0 up and running on Debian Wheezy (= Stable) or on
other more conservative linux distribution wasn't exactly easy as the 
VM's provided by the Pharo team fail to run on those systems. 

Well, not any longer. You may find precompiled binaries at: 

https://swing.fit.cvut.cz/jenkins/view/Projects/job/pharo-vm-stable-swing/

or use zeroconf script: 

curl http://swing.fit.cvut.cz/download/pharo/vm-swing | bash

or 

wget -O- http://swing.fit.cvut.cz/download/pharo/vm-swing | bash

The VM is compiled from pre-generated sources found at:

http://files.pharo.org/vm/src/vm-unix-sources/blessed/pharo-vm-2014.09.20.tar.bz2

Thanks to Clement, Damien & Markus for their help. 

Have fun. 

Jan

Re: [Pharo-dev] Building .deb with Pharo VM

[Jan Vrany]

Hi Damien, 

On Fri, 2014-09-26 at 17:56 +0200, Damien Cassou wrote:
> On Fri, Sep 26, 2014 at 9:42 AM, Jan Vrany  wrote:
> > However, I already exhausted my free time. I'll try again later and
> > get back to you.
> 
> 
> I created a job that builds a nice archive with pre-patched sources:
> http://files.pharo.org/vm/src/vm-unix-sources/blessed.
> 

Very nice indeed. This one works like a charm. Thank you very much. 
Best, Jan

Re: [Pharo-dev] Building .deb with Pharo VM

[Jan Vrany]

Hi Markus & Damien, 

Markus, thanks for the hint, I'll try. Damien,
yes, the problematic patch was source-hardening.patch
as Markus pointed out. And then also something about
native vs. quilt package format. 

So far I struggled with recipe given by Clement, mainly 
because of libgit2 - it refuses to compile cleanly in 32bit mode
under 64bit system (I had this problem 2 years ago when playing
with libgit2, apparently no progress here :-) Bit of sed would do it,
although super ugly. Then the vm generator generated sources to the
wrong directory. It either does not respect process CWD os it was
something else...

However, I already exhausted my free time. I'll try again later and
get back to you. 

Best, Jan

On Thu, 2014-09-25 at 15:37 +0200, Markus Fritsche wrote:
> On 2014-09-25 13:58, Damien Cassou wrote:
> 
> >> I tried that,but some patches applied to the sources above are rejected
> >> so package dpkg-buildpackage fails - at least on Debian Jessie
> 
> > can you give more information?
> 
> source-hardening.patch has to be adjusted
> 
> --- a/src/vm/cogit.c2014-09-24 11:26:13.117242533 +0200
> +++ b/src/vm/cogit.c2014-09-24 11:26:55.181154041 +0200
> @@ -19339,7 +19339,7 @@ printTrampolineTable(void)
> for (i = 0; i < trampolineTableIndex; i += 2) {
> printHex(((sqInt)(trampolineAddresses[i + 1])));
> print(": ");
> -   print(((char *) (trampolineAddresses[i])));
> +   printf("%s", trampolineAddresses[i]);
> cr();
> }
>  }
> 
> 
> Kind regards,
>   Markus
> 

Re: [Pharo-dev] Building .deb with Pharo VM

[Jan Vrany]

Hi Damien, 

thanks! 

> you may want to use this ones instead to produce a deb file:
> https://github.com/pharo-project/pharo-ci/tree/master/ci-jobs/pharo/Pharo-vm-unix-sources.
> This is because some patches are applied and compiling the sources
> won't require downloading some dependencies.

> Moreover, I've written scripts to generate deb files for Ubuntu:
> https://github.com/pharo-project/pharo-ubuntu/tree/master/pharo-vm-core-i386.
> 

I tried that,but some patches applied to the sources above are rejected
so package dpkg-buildpackage fails - at least on Debian Jessie :-) 

Best, Jan

Re: [Pharo-dev] Building .deb with Pharo VM

[Jan Vrany]

Thanks a lot! 

Jan


On Thu, 2014-09-25 at 07:18 +0200, Clément Bera wrote:
> Hello Jan,
> 
> 
> Here it is:
> 
> 
> #!bash -lex
> 
> 
> cd "$WORKSPACE"
> # Set environment
> 
> ZIP_FILTER='*'
> if [ "$OS" == "win" ]; then
> set -e # Stop the execution if a command fails!
> ZIP_FILTER=' *.exe *.dll'
> fi
> 
> 
> # Download the latest sources
> 
> wget --quiet files.pharo.org/vm/src/vmmaker-image.zip
> wget --quiet files.pharo.org/vm/src/cog.tar.gz
> 
> 
> # Unpack sources
> =
> tar -xzf cog.tar.gz || echo # echo needed for Windows build (error on
> symlinks creation)
> mkdir -p cog/build
> mkdir -p cog/image
> 
> 
> cd cog/image
> unzip -o ../../vmmaker-image.zip
> 
> 
> # Generate sources
> ===
> echo "
> PharoVMBuilder buildOnJenkins: '$OS'.
> Smalltalk snapshot: false andQuit: true." > ./script.st
> 
> 
> wget -O- get.pharo.org/vm | bash
> ./pharo generator.image script.st || (cat stderr; exit 1)
> 
> 
> cd ../../
> tar -czf sources.tar.gz -C cog .
> 
> 
> 
> 
> # Compile
> 
> cd cog/build
> sh build.sh
> 
> 
> 
> 
> # Archive
> ========
> cd "$WORKSPACE/cog/results"
> 
> 
> zip -r "vm.zip" $ZIP_FILTER
> 
> 
> cp -f vm.zip ../../"${BUILD_NUMBER}.zip"
> cp -f vm.zip ../../"latest.zip"
> mv -f vm.zip ../../"Pharo-VM-${OS}-latest.zip"
> 
> 
> # success
> exit 0
> 
> 2014-09-24 23:27 GMT+02:00 Jan Vrany :
> Hi there,
> 
> could somebody with access send me please the configuration of
> Pharo VM job
> (https://ci.inria.fr/pharo/view/4.0-VM/job/PharoVM/)
> Namely build steps :-)
> I'd like to build the VM on my Jenkins...
> 
> Thanks, Jan
> 
> 
> 
> 

[Pharo-dev] Building .deb with Pharo VM

[Jan Vrany]

Hi there, 

could somebody with access send me please the configuration of
Pharo VM job (https://ci.inria.fr/pharo/view/4.0-VM/job/PharoVM/)
Namely build steps :-)
I'd like to build the VM on my Jenkins...

Thanks, Jan

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

[Jan Vrany]

> Wasn't Smalltalk/X the one which had a more complete version of 
> that C translation? 

Yes. Smalltalk/X **still** compiles Smalltalk to C (bytecode
interpreting and JITing modes are also supported, of course). 

Best, Jan

Re: [Pharo-dev] AppeX

[Jan Vrany]

Hi Torsten, Phil, 

On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote:
> Hi Phil,
> 
> if there is something I would like to see our Pharo ecosystem and ST in 
> general moving 
> towards is to such a "multilanguage"/"multisourcecode"/"flexible ressources" 
> kind of
> thing. Even when this could not be a short term goal I would like to see this
> in the long term. 

I've been working in this area for many years now. And have learned a
good deal while doing that :-) 
Making one language to execute within other's environment is the easy
part, though it could be a lot of work (especially, if you care about 
performance). Making tools to be aware of different languages is not
hard too, thought it is "just" a huge amount of work that has to be
done. The tricky part is to allow one to talk to each other, preserving
each other's semantics and still stay intuitive, clear and free of
unnecessary boilerplate code. Another tricky bit is to make other
workflows and ways of coding things in other languages work nicely with
the way Smalltalk way we do it in Smalltalk. These are tough bits.
That's where a real research has yet to be done...

>  - running Java inside of Smalltalk/X 

Well, Smalltalk/X can do much more with Java than "just" run it. 
Java has been fully integrated into development tools supporting full 
development cycle :-)

Re: [Pharo-dev] Should nested mutexes work in Pharo 3.0?

[Jan Vrany]

On 31/07/14 10:45, Marcel Taeumel wrote:

Hi! :)

I am playing around with Animations [1] in the Moose 5.0/Pharo 3.0 image
[2]. Nested use of the same mutex seems to freeze the image. Should that
work?


No, it should not :-) Use Monitor instead.

Jan



Best,
Marcel

[1] https://github.com/marceltaeumel/animations
[2]
https://ci.inria.fr/moose/job/moose-5.0/lastSuccessfulBuild/artifact/moose-5.0.zip



--
View this message in context: 
http://forum.world.st/Should-nested-mutexes-work-in-Pharo-3-0-tp4771110.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] How to close all inspector windows ?

[Jan Vrany]

On 21/07/14 17:46, Esteban Lorenzano wrote:


On 21 Jul 2014, at 18:40, Peter Uhnák mailto:i.uh...@gmail.com>> wrote:


> We should not get limited in spawning inspectors, I think.
My question is... is there any legitimate reason to have opened
hundreds of any type of window? Whether they are browser, debugger,
inspector or anything else. At least to me that would seem like an error.


is there any legitimate reason to forbid it?
placing artificial restrictions in base of “what we think it should be”
is definitively a bad a idea. Both for programming and life.
(also, being able to restrict, filter, etc. in taskbar is a better idea,
and a non-restrictive one)

Esteban


What about a token bucket sort of mechanism? This protects well against
window bomb and does not impose any artificial limit at the same time.

Best. Jan





On Mon, Jul 21, 2014 at 6:30 PM, Esteban Lorenzano
mailto:esteba...@gmail.com>> wrote:


On 21 Jul 2014, at 18:26, Guillermo Polito
mailto:guillermopol...@gmail.com>> wrote:


+1 to Doru.


+1



In addition, if managed at the inspector level, you'll have the
same problem with the debuggers and any other easily-spawned window.


On Mon, Jul 21, 2014 at 6:24 PM, Tudor Girba
mailto:tu...@tudorgirba.com>> wrote:

I think the issue should be addressed at the level of the
TaskbarMorph. That should be the one that gets limited, for
example, by providing a "more windows" button.

We should not get limited in spawning inspectors, I think.

Cheers,
Doru


On Mon, Jul 21, 2014 at 3:58 PM, stepharo mailto:steph...@free.fr>> wrote:


On 21/7/14 10:29, Peter Uhnák wrote:

Wouldn't it be easier to simply enforce fixed limit of
Inspector/Debug instances (e.g. 10 or 20)? After
reaching the limit creation of more would be simply
ignored. Because as a victim I don't see much use of
having vastly more windows than even fit on the screen
especially since most of the erroneous windows are
actually identical.


yes this is a nice idea.
If somebody is ready for the challenge, please try and we
will integrate it.




Peter


On Mon, Jul 21, 2014 at 10:00 AM, p...@highoctane.be
 mailto:p...@highoctane.be>> wrote:

It would be nice to have the toolbar have some kind
of Win7 spinner to the right to solve this.

Is there a way to know when a system window was opened?

Who hasn't been a victim of the attack of the too
many windows popping up all over?

Phil

Le 21 juil. 2014 02:12, "Ben Coman"
mailto:b...@openinworld.com>> a
écrit :

kilon alios wrote:

I am afraid I could not do that, it seems that
when pharo has opened too many windows the
bottom bar takes all the space of the pharo
windows and because it has higher viewer
priority you cannot view any kind of window.
All you see is that bars that represent open
windows filling your screen.


That is a problem.

https://pharo.fogbugz.com/f/cases/13618/Toolbar-should-never-fill-more-than-half-the-screen



So the solution for me was to reopen the image
, fetch most of my lost code from changes  and
fortunately only add a few lines of code back
that were permanently lost.

So a big thank you for changes , it saved me at
least hours of work and thank you for trying to
help me.


On Sun, Jul 20, 2014 at 6:13 PM, Ben Coman
mailto:b...@openinworld.com>> wrote:

As Peter said, you can execute any code in
an inspector window.  Here is how you might
solve this yourself :)
There is a menu option
World > Windows > Delete unchanged windows.
Of course, you can't use that directly
since your background is covered with
windows.  But you could open up another
image and then do this...
1. Bring up the halos on that menu option
2. Click the "Debug" spanner icon and
choose 'Inspect Morph'
3. Scroll down to /target/  where you find
"[ World closeUnchangedWindows ]"
4. Evaluate that back in the problem image
in

Re: [Pharo-dev] [ANN] Ephestos - Using and Coding Blender from inside Pharo

[Jan Vrany]

The goal of Atlas, is to create a two way communication socket
bridge between cpython (most popular python implementation) and
pharo. Very similar to Ephestos but you will no longer need Blender.
That means that pharo coders will be able to use python libraries
from inside pharo and even mix python with pharo code. So you could
make part of your application in python and part in pharo and still
function as a single application.


I am interested in Atlas. Do you have a link?



This has been done some three years ago for OpenQwak :-)

http://squeakingalong.wordpress.com/2011/05/04/openqwaq-python-integration/

Best, Jan

Re: [Pharo-dev] vm over android

[Jan Vrany]

Hi,


Yes there is a business interest of running on ARM processors. Some of
the big companies use smalltalk on their own hardware for very specific
tasks, and they are now constraint to use x86 processor due to smalltalk.


There are other smalltalks that run on non-x86 && non-amd64 machines.
Smalltalk ~~ Pharo :-)

Jan

Re: [Pharo-dev] NativeBoost and WKHTML

[Jan Vrany]

Hi,

If I were to debug this, I would:

1 ) make sure there's no C++ interfering, try to compile using C
compiler (not C++, I guess you run Windows  and MSVC, I think
there's command line option to process file as C).
If not possible, wrap all methods you want to call form St
in extern "C" {} block. Does it work? If not, then C++ compiler
is doing it's magic which NB doesn't.


2 ) If it does, run whole thing under debugger, set breakpoint to
the faulty function and check that arguments are correct
and what's return value.
If args are incorrect, then the problem is in either yours or
NB's code.
If return value is correct, then the problem is also in
either yours or NB's code.
If the return value is incorrect, well then the problem could be
either in the library or some sort of GC thing as GC moves stuff
around, which most of C/C++ libraries don't like much.

In that case, I learned, the only way us to read library's code
and single-step through it to see that the code actually does with
data you pass down.

HTH, Jan



On 23/05/14 10:51, Torsten Bergmann wrote:

Hi Jean,

thanks for answering. I dont think that the convention is an issue here: 
internally
it is written in C++, but it exposes the API as simple C functions. The calls 
with NB
work (even the callbacks).

What confuses me most is that the call to "wkhtmltopdf_set_global_setting"
works while the "wkhtmltopdf_set_object_setting"  does not. They have exactly
the same signature and are called one after the other. First one returns proper 
int 1 (success)
as in the non-Smalltalk example, the other one 0 which means it failed.

There is no magic in the Pharo code, just simple calls. Also the non-Smalltalk 
example
proves that the component is working. Maybe a side effect of NativeBoost itself?

Looks like so far I'm lost without the help of Igor here...

Thx
T.



Gesendet: Freitag, 23. Mai 2014 um 11:31 Uhr
Von: "Jean Baptiste Arnaud" 
An: "Pharo Development List" 
Betreff: Re: [Pharo-dev] NativeBoost and WKHTML

I think this is because it is a C++ lib.
NativeBoost cannot be used with C++ lib.
It is a problem of call convention that is not the same from C to C++.
As I discuss with some people it seems be a complexe problem, each C++ compiler 
seems have it own convention.
But Igor can maybe be more accurate about that.
A C wrapper to call C++, which should work.



On 23 May 2014, at 02:36, Torsten Bergmann  wrote: Hi,

as there was no responded so far I tried to track the problem deeper and did a 
short test
client in C/C++ to verify if I can call WKHTMLTOPDF there and generate a PDF 
and to
compare to the Pharo/NativeBoost client.

Attached is the according CPP file which works and results in a PDF with the 
google
homepage.

I also additionally implemented the callback functions in the Pharo wrapper and
using the error handling I noticed that the component returns "Failed loading page 
http:// ..."


With that info I compared the C/C++ calls to the Pharo/NativeBoost calls more 
deeply and
found out that in C/C++ the following call for an object setting works (by 
returning 1):


// this returns 1 in C/C++ which is OK
int a = wkhtmltopdf_set_object_setting(os, "page", 
"http://www.google.de[http://www.google.de]";);
printf("object set %i",a);


while in Pharo the same call fails (by returning 0):

"The following call failed and returns 0 instead of 1"
self setObjectSetting: 'page' to: 'http://www.google.de'[http://www.google.de'] 
in: os.

I checked how I wrapped this API call again and again - it is fine from my side:

setObjectSetting: aName to: value in: settings



^NBFFICallout stdcall: #(int 
wkhtmltopdf_set_object_setting(wkhtmltopdf_object_settings* settings, char* 
aName, char* value)) module: 'wkhtmltox.dll'

and I still have no idea why it fails.

Especially because "wkhtmltopdf_set_object_setting" function is not different from 
"wkhtmltopdf_set_global_setting" which is exactly the same way wrapped, works
and returns 1 in exactly the same example.

I would really appreciate if someone could have a second look...

To reproduce on Windows:

1. Download the 32 bit version of WKHTML from 
http://wkhtmltopdf.org[http://wkhtmltopdf.org] and install it
2. Copy the "wkhtmltox.dll" to either the folder of the VM executable
or the Windows directory so it can be found
3. Load the package WKHTML2PDF-Core-TorstenBergmann.7
from 
http://smalltalkhub.com/#!/~TorstenBergmann/WKHTML2PDF[http://smalltalkhub.com/#!/~TorstenBergmann/WKHTML2PDF]
 into Pharo 3.0#30848
4. Check the Transcript while evaluating:

WKPDFLibrary example

One can see that within this code #setObjectSetting:to:in: fails while 
#setGlobalSetting:to:in:
works.

Maybe I just do not see the obvious. Help is appreciated. Thanks in advance!

bye
T.




Best Regards
Jean Baptiste Arnaud
jbaptiste.arn...@gmail.com[jbaptiste.arn...@gmail.com]

Re: [Pharo-dev] Clarifications with small lint rules

[Jan Vrany]

No. not really.

There are just 4 implementors only, in RBBasicLintRule, 
RBTransformationRule and RBCompositeLintRule.


Maybe I've added something to environment, I don't really remember, it's 
a long time ago when worked on this and since then it just works :-)


If you'd like more convenient way to browse the code, you may want to
download and run St/X and look at it in browser:

https://swing.fit.cvut.cz/projects/stx-jv/wiki/Download

SmallLint is pre-loaded.

Jan


On 22/05/14 16:18, Yuriy Tymchuk wrote:

Hi Jan,

in #failedMethods: you use #failedMethodsInto: which is abstract. So the idea 
is that in each rule gets methods from it’s result?

Uko


On 22 May 2014, at 17:03, Jan Vrany  wrote:


Yeah,

all the refatory stuff has weird API and SmallLint ones are of the weirdest. 
The design is bit unfortunate.
You may want to have a look how I did it:

RBLintRule>>failedMethods, RBLintRule>>failedClasses

source code's here:
http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/RBLintRule.st?view=markup

Best, Jan


On 22/05/14 15:49, Yuriy Tymchuk wrote:

Hi guys,

so I’m experimenting with rules, and I have one simple question: how do I get a 
collection of items from some environment which violate some rule?

i know that I can send #runOnEnvironment: to the rule itself and then it will 
use a checker to run the rule on the environment. But later I end up with the 
rule itself. I know that I can get all atomic rules from composite rule by 
sending #leaves, and there is #result method that returns environment. But 
there is no single way to get items from environment, and all accessors are 
environment-specific. Am I doing something wrong? Because I’ve spent half of a 
day to find out how to run a rule and get violations :).

Cheers.
Uko

Re: [Pharo-dev] Clarifications with small lint rules

[Jan Vrany]

Yeah,

all the refatory stuff has weird API and SmallLint ones are of the 
weirdest. The design is bit unfortunate.

You may want to have a look how I did it:

RBLintRule>>failedMethods, RBLintRule>>failedClasses

source code's here:
http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/RBLintRule.st?view=markup

Best, Jan


On 22/05/14 15:49, Yuriy Tymchuk wrote:

Hi guys,

so I’m experimenting with rules, and I have one simple question: how do I get a 
collection of items from some environment which violate some rule?

i know that I can send #runOnEnvironment: to the rule itself and then it will 
use a checker to run the rule on the environment. But later I end up with the 
rule itself. I know that I can get all atomic rules from composite rule by 
sending #leaves, and there is #result method that returns environment. But 
there is no single way to get items from environment, and all accessors are 
environment-specific. Am I doing something wrong? Because I’ve spent half of a 
day to find out how to run a rule and get violations :).

Cheers.
Uko

Re: [Pharo-dev] Immutable collections and encapsulation

[Jan Vrany]

On 13/05/14 15:50, Alexandre Bergel wrote:

I got an interest some years ago, to see if Context-Oriented-Programming would 
help to have immutable collections.

Apparently, Java supports immutability at runtime (i.e., there is no class 
ImmutableArrayList as far as I know).


Actually there is. Have a look at java.util.Collections, 
java.util.Collections.UnmodifiableList/UnmodifiableRandomAccessList in 
particular. Many libraries define their own immutable collections as far 
as I have seen.


There's no support for object immutability in the OpenJDK-based JVMs.

Cheers, Jan


So, there is no good design for immutable collections as far as I know. I read 
something about that on Doug Lea web page.

Cheers,
Alexandre

Re: [Pharo-dev] How to decompile a block?

[Jan Vrany]

Works like a charm, thanks!

Jan

On 04/04/14 09:51, Marcus Denker wrote:


On 04 Apr 2014, at 09:45, Jan Vrany  wrote:


Hi,

Decompiler>>decompileBlock: vanished in 3.0 (present in 2.0).
What's the code for doing the same in 3.0?



you call #sourceNode:

[ 1 + 2 ] sourceNode

Marcus

[Pharo-dev] How to decompile a block?

[Jan Vrany]

Hi,

Decompiler>>decompileBlock: vanished in 3.0 (present in 2.0).
What's the code for doing the same in 3.0?

Jan

P.S.: Copy-paste of code from 2.0 to 3.0 does not work,
not a big surprise :-)