Re: [Pharo-project] PipeableOSProcess under windows

[Eliot Miranda]

On Mon, May 6, 2013 at 6:55 AM, Camillo Bruni camillobr...@gmail.comwrote:

 Am I correct in the assumption that OSProcess does not properly use the
 Path env variable?
 I have MinGW installed and the Path variable is set up correctly, so I do

 bash --help

 in the CMD window, however something like `OSProcess waitForCommand: 'bash
 --help'` does not work.


I suspect you have to launch it with the -l flag to make bash act as if it
had been invoked as a login shell.

HTH


 Is there a workaround for this issue?




-- 
best,
Eliot

Re: [Pharo-project] Moment of fun

[Eliot Miranda]

On Tue, Apr 30, 2013 at 12:52 PM, Stéphane Ducasse 
stephane.duca...@inria.fr wrote:

 Hi guys

 I would like to build a small lectures based on all the small little crazy
 expressions that we use
 like

 StandardWindow allInstances do: #close.

 or

 myObject pointersTo

 or

 anObject become: String new.

 Do you have some cool expressions to share with me.

 Stef


my favourite, used to lock up Smalltalk VMs:

| pair |
pair := { #perform:withArguments:. nil }.
pair at: 2 put: pair.
pair perform: pair first withArguments: pair.

-- 
best,
Eliot

Re: [Pharo-project] RE : cannot modify class comments on Linux

[Eliot Miranda]

Hi Sven,

On Fri, Apr 26, 2013 at 4:15 AM, Sven Van Caekenberghe s...@stfx.eu wrote:


 On 26 Apr 2013, at 12:44, Igor Stasenko siguc...@gmail.com wrote:

  On 26 April 2013 10:27, Pavel Krivanek pavel.kriva...@gmail.com wrote:
  The reason is in the optimalizations in the latest glibc. It really
 does not
  write the new content to the changes file immediately. We need to call
 flush
  at the end of nextChunkPut:
 
  This is nasty one.
  What i worry that it affects much more than code working with .changes
 file.

 Why ? Isn't that standard behavior/semantics: unless you flush you cannot
 be sure anything is actually out of the OS' buffers. And even then, disks
 and RAID cards are known to lie and sometimes don't write data out even
 when flush is called.


But the issue is whether the read is through the same file pointer as the
write or not.  If the read is made through the same file pointer (or a
dup'ed file pointer) then the data should be in the buffer and the read
should see it, and if so, then this is a bug in either glibc (if the FILE *
info is not properly synchronised) or (unlikely) the kernel.  If it is
through a separate file pointer then yes, the problem is a missing flush.
 Which is it?


 In networking (TCP streams) this is similar.

  Cheers,
  -- Pavel
 
 
  On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry 
 thierry.goub...@cea.fr
  wrote:
 
  Reproduced on Ubuntu 13.04.
 
  Class organization remoteString filePositionHi is past the end of the
  changes file (i.e. exactly equal to the file size if the comment is
 the last
  operation).
 
  Thierry
  
  De : pharo-project-boun...@lists.gforge.inria.fr
  [pharo-project-boun...@lists.gforge.inria.fr] de la part de Pavel
 Krivanek
  [pavel.kriva...@gmail.com]
  Date d'envoi : jeudi 25 avril 2013 21:32
  À : Pharo-project@lists.gforge.inria.fr
  Objet : Re: [Pharo-project] cannot modify class comments on Linux
 
  Jaroslav wrote this:
  This does work on F17, but it doesn't work on F18, F19. Maybe glibc
 issue?
  I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15
 same
  as F17, so I guess this would be also reproducible on Ubuntu 13.04.
 
  -- Pavel
 
  On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi 
 giseladecu...@gmail.com
  wrote:
 
  I'm on 64-bit Ubuntu 12.04
 
 
  2013/4/25 Pavel Krivanek pavel.kriva...@gmail.com
 
  Hi,
 
  what architecture and distro do you use because I tried it on a
 32-bit
  Debian and it worked. I'm on 64-bit Fedora 18. That may be the
 reason why
  the tests are not failing on CI. This error appears on all old system
  classes and on newely created classes too.
  Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
 
  -- Pavel
 
  On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi
  giseladecu...@gmail.com wrote:
 
  Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me.
 (just
  try in a random class comment)
  Are you trying to modify a particular class comment?
 
 
  2013/4/25 Pavel Krivanek pavel.kriva...@gmail.com
 
  Hi,
 
  if you will try to modify a class comment on Linux, the error
  RemoteString past end of file will appear. On windows VM it
 seems to work
  well. Can someone confirm this behavior on Linux. Squeak has the
 same
  problem.
 
  Cheers,
  -- Pavel
 
 
 
 
 
 
 
 
 
  --
  Best regards,
  Igor Stasenko.
 





-- 
best,
Eliot

Re: [Pharo-project] DateAndTime bug: we should do something about it

[Eliot Miranda]

On Wed, Apr 17, 2013 at 2:31 AM, Henrik Johansen 
henrik.s.johan...@veloxit.no wrote:


 On Apr 16, 2013, at 7:50 PM, Eliot Miranda wrote:



 On Tue, Apr 16, 2013 at 2:56 AM, Igor Stasenko siguc...@gmail.com wrote:

 On 16 April 2013 11:32, Henrik Johansen henrik.s.johan...@veloxit.no
 wrote:
 
  On Apr 15, 2013, at 4:50 PM, Igor Stasenko wrote:
 
  On 15 April 2013 16:43, Igor Stasenko siguc...@gmail.com wrote:
  On 15 April 2013 16:32, Henrik Johansen henrik.s.johan...@veloxit.no
 wrote:
 
  On Apr 15, 2013, at 3:25 PM, Igor Stasenko wrote:
 
  On 15 April 2013 12:14, Henrik Johansen 
 henrik.s.johan...@veloxit.no wrote:
 
  On Apr 13, 2013, at 12:16 AM, Igor Stasenko wrote:
 
 
  But that's fine.. now look at
 
  secondsWhenClockTicks
 
  waits for the moment when a new second begins
 
  | lastSecond |
 
  lastSecond := self primSecondsClock.
  [ lastSecond = self primSecondsClock ] whileTrue: [ (Delay
  forMilliseconds: 1) wait ].
 
  ^ lastSecond + 1
 
  that is complete nonsense. Sorry.
 
  This code relying on primSecondsClock resolution, which is.
 (drum
  roll. )
  1 second..
 
  then it is combined with millisecondClockValue , as you see later
 to get
  system time with millisecond precision..
 
  I am not genius in math and physics.. but even i understand that
 if
  you measurement has error X
  you cannot get more precision than X, even if you combine it with
  another measurement with higher precision.
 
  (But i can be wrong with that.. if so, please explain why)
 
  Because, as Levente said in code, resolution  != accuracy.
  When you measure a single sample, sure, that value has an error of
 max resolution / 2.
  But when you measure when that value _changes_, you have an error
 of the underlying accuracy / 2.
  Clock s value:  1   2
  resolution: |___|___|
  accuracy:   |||
 ^
  Here's to hoping the above ascii art(?) worked!
 
  So no, that method is not complete nonsense.
 
  Okay.
  Now i rewriting the code which uses new primitive
 (primUTCMicrosecondClock),
  and then we will no longer need this startup logic nor wrap around
  check  other gory details...
  just use a primitive.
 
  Sounds clearer, yes.
 
  However, be aware, at least on my VM:
  [Time millisecondClockValue] bench '34,600,000 per second.'
  [Time primUTCMicrosecondClock] bench '12,400,000 per second.'
 
  Which in my case translated to that in a Time2 class with #now
 defined:
  now
 
 | microSecondsToday |
 microSecondsToday := self primUTCMicrosecondClock \\
 864.
 ^ self seconds: microSecondsToday // 100 nanoSeconds:
 microSecondsToday * 1000
 
  and changing the relatively low-hanging fruit in standard Time
 (removing Duration creation and other crap):
 
  seconds: seconds nanoSeconds: nanoCount
 Answer a Time from midnight.
 
 ^ self basicNew
 seconds: seconds nanoSeconds: nanoCount
 
  To benchmarks that looked like this:
  Old code
  [Time now ] bench '7,330,000 per second.' '7,280,000 per second.'
 '7,170,000 per second.'
  Using microsecondClock every call
  [Time2 now ] bench  '2,280,000 per second.''2,300,000 per second.'
 '2,180,000 per second.'
 
  Also note, Time2 lacked translation to Local time, which would be
 needed for consistency with Time now.
 
 
  Well, i am not started modifying Time now, (will start in couple
 minutes ;)
  but here results of DateAndTime now
  before and after:
 
  before:
 
 
  [ DateAndTime now ] bench '316,000 per second.'
 
  after:
 
  [ DateAndTime now ] bench '414,000 per second.'
 
 
  with Time now, i think even if it will be 2,300,000 answers per
 second,
  it is fairly acceptable , when accuracy of primitive is 1 microsecond,
  you actually don't need more than 1 million answers per second, or you
  will receive same answers.
 
  But aside of it, may i ask, why performance is so important/critical
  for those? What is use case?
 
 
  everything is good in comparison:
 
  [ self yourself ] bench '58,800,000 per second.'
 
  does nothing and just 25 times faster.. than Time now,
  so what is the point? :)
 
  The point was raising awareness that performance differences are also
 worthy of measuring when doing a reimplementation, not just code
 cleanliness.
  A 3x decrease in performance is worth at least consideration as part of
 a reimplementation, even when the conclusion is it's plenty fast enough
 for most uses anyways.
 
  Not to mention, Made X Y% faster looks better in the release notes
 than Restructured the internals of X :)
 
 RIght.
 So, it is 3x slower , 1000x more accurate (milli vs micro), do not
 requires startup code
 do not need to account for counter wrapping and day change = much
 cleaner and nicer.
 + less buggy.
 As to me , the choice is obvious.


 and when we implement a proper 64-bit

Re: [Pharo-project] DateAndTime bug: we should do something about it

[Eliot Miranda]

On Tue, Apr 16, 2013 at 2:56 AM, Igor Stasenko siguc...@gmail.com wrote:

 On 16 April 2013 11:32, Henrik Johansen henrik.s.johan...@veloxit.no
 wrote:
 
  On Apr 15, 2013, at 4:50 PM, Igor Stasenko wrote:
 
  On 15 April 2013 16:43, Igor Stasenko siguc...@gmail.com wrote:
  On 15 April 2013 16:32, Henrik Johansen henrik.s.johan...@veloxit.no
 wrote:
 
  On Apr 15, 2013, at 3:25 PM, Igor Stasenko wrote:
 
  On 15 April 2013 12:14, Henrik Johansen 
 henrik.s.johan...@veloxit.no wrote:
 
  On Apr 13, 2013, at 12:16 AM, Igor Stasenko wrote:
 
 
  But that's fine.. now look at
 
  secondsWhenClockTicks
 
  waits for the moment when a new second begins
 
  | lastSecond |
 
  lastSecond := self primSecondsClock.
  [ lastSecond = self primSecondsClock ] whileTrue: [ (Delay
  forMilliseconds: 1) wait ].
 
  ^ lastSecond + 1
 
  that is complete nonsense. Sorry.
 
  This code relying on primSecondsClock resolution, which is.
 (drum
  roll. )
  1 second..
 
  then it is combined with millisecondClockValue , as you see later
 to get
  system time with millisecond precision..
 
  I am not genius in math and physics.. but even i understand that if
  you measurement has error X
  you cannot get more precision than X, even if you combine it with
  another measurement with higher precision.
 
  (But i can be wrong with that.. if so, please explain why)
 
  Because, as Levente said in code, resolution  != accuracy.
  When you measure a single sample, sure, that value has an error of
 max resolution / 2.
  But when you measure when that value _changes_, you have an error
 of the underlying accuracy / 2.
  Clock s value:  1   2
  resolution: |___|___|
  accuracy:   |||
 ^
  Here's to hoping the above ascii art(?) worked!
 
  So no, that method is not complete nonsense.
 
  Okay.
  Now i rewriting the code which uses new primitive
 (primUTCMicrosecondClock),
  and then we will no longer need this startup logic nor wrap around
  check  other gory details...
  just use a primitive.
 
  Sounds clearer, yes.
 
  However, be aware, at least on my VM:
  [Time millisecondClockValue] bench '34,600,000 per second.'
  [Time primUTCMicrosecondClock] bench '12,400,000 per second.'
 
  Which in my case translated to that in a Time2 class with #now
 defined:
  now
 
 | microSecondsToday |
 microSecondsToday := self primUTCMicrosecondClock \\
 864.
 ^ self seconds: microSecondsToday // 100 nanoSeconds:
 microSecondsToday * 1000
 
  and changing the relatively low-hanging fruit in standard Time
 (removing Duration creation and other crap):
 
  seconds: seconds nanoSeconds: nanoCount
 Answer a Time from midnight.
 
 ^ self basicNew
 seconds: seconds nanoSeconds: nanoCount
 
  To benchmarks that looked like this:
  Old code
  [Time now ] bench '7,330,000 per second.' '7,280,000 per second.'
 '7,170,000 per second.'
  Using microsecondClock every call
  [Time2 now ] bench  '2,280,000 per second.''2,300,000 per second.'
 '2,180,000 per second.'
 
  Also note, Time2 lacked translation to Local time, which would be
 needed for consistency with Time now.
 
 
  Well, i am not started modifying Time now, (will start in couple
 minutes ;)
  but here results of DateAndTime now
  before and after:
 
  before:
 
 
  [ DateAndTime now ] bench '316,000 per second.'
 
  after:
 
  [ DateAndTime now ] bench '414,000 per second.'
 
 
  with Time now, i think even if it will be 2,300,000 answers per
 second,
  it is fairly acceptable , when accuracy of primitive is 1 microsecond,
  you actually don't need more than 1 million answers per second, or you
  will receive same answers.
 
  But aside of it, may i ask, why performance is so important/critical
  for those? What is use case?
 
 
  everything is good in comparison:
 
  [ self yourself ] bench '58,800,000 per second.'
 
  does nothing and just 25 times faster.. than Time now,
  so what is the point? :)
 
  The point was raising awareness that performance differences are also
 worthy of measuring when doing a reimplementation, not just code
 cleanliness.
  A 3x decrease in performance is worth at least consideration as part of
 a reimplementation, even when the conclusion is it's plenty fast enough
 for most uses anyways.
 
  Not to mention, Made X Y% faster looks better in the release notes
 than Restructured the internals of X :)
 
 RIght.
 So, it is 3x slower , 1000x more accurate (milli vs micro), do not
 requires startup code
 do not need to account for counter wrapping and day change = much
 cleaner and nicer.
 + less buggy.
 As to me , the choice is obvious.


and when we implement a proper 64-bit system with e.g. 61-bit SmallIntegers
it will no longer be 3 times slower :)



  Cheers,
  Henry
 
 



 --
 Best regards,
 Igor Stasenko.




-- 

Re: [Pharo-project] Open window out of my pharo environment

[Eliot Miranda]

On Fri, Apr 12, 2013 at 12:49 AM, Tristan Bourgois 
tristan.bourg...@gmail.com wrote:

 Hi!

 all my question is in the object ^^

 Does exist the possibility to open a window out of my pharo environment?
 (Or someone know the way to do that?)


google: Squeak VNC server



 I'm working on a graphic framework and at my work they need a multi screen
 support. It's needed to validate Pharo as the smalltalk they will use!

 Thanks!

 Tristan




-- 
best,
Eliot

Re: [Pharo-project] [Preview] Branch test coverage analysis tool for Pharo 3.0 :)

[Eliot Miranda]

On Mon, Apr 8, 2013 at 9:32 AM, Alexandre Bergel alexandre.ber...@me.comwrote:

 What I had in mind, is something like:
 -=-=-=-=-=-=-=-=-=-=
 myMethodWithBranch
 self foo.
 v
 ifTrue: [ ... ]
 ifFalse: [ ... ]
 -=-=-=-=-=-=-=-=-=-=

 -=-=-=-=-=-=-=-=-=-=
 myMethodWithBranch
 self foo.
 v
 ifTrue: [ *self checkPoint: 1.* ... ]
 ifFalse: [ *self checkPoint: 2.* ... ].
 *self checkPoint: 3.*
 -=-=-=-=-=-=-=-=-=-=

 All these checkpoint will be inserted by manipulating the bytecode. You
 can then optimize a bit by removing checkpoints that have been reached.
 The method #checkPoint: could then use some attributes to the
 CompiledMethod.

 This is a common technique when (i) the VM does not give you what you need
 and (ii) when you do not want to change the VM.


I just implemented something to this effect for our project at Cadence.  It
works by
- an assembler/disassebler that can convert a method into a sequence of
messages, one for each of its bytecodes and back
- using the disassembler to obtain labels which occur at the start of each
basic block
- replacing the first bytecode in every basic block with an illegal
bytecode, remembering the pc and its correct bytecode in the method
properties
- implementing a method on MethodContext which receives the unknowBytecode
message sent by the VM when it encounters an illegal bytecode
- the method replaces the illegal bytecode with the correct bytecode,
removing the entry from properties, and continues

The JIT refuses to compile methods that contain illegal bytecodes so this
runs at interpreter speed until a method no longer contains illegal
bytecodes (has been completely covered).  But the illegal bytecode is
executed at most once for each basic block, since it is replaced
immediately it is executed.  The information remaining in properties is
that of the basic blocks that have not been executed.

In the Squeak/Pharo bytecode set there are three unknown bytecodes, 126,
127  139.  I have a Monticello package and tests if you're interested.



 This is something I wanted to do for year in Hapao...

 Alexandre



 On Apr 7, 2013, at 3:21 AM, Clément Bera bera.clem...@gmail.com wrote:

 I don't know. The main problem is that the AST-interpreter is not fast
 enough. The best solution for speed would be to improve it as they do in
 this paper : http://dl.acm.org/citation.cfm?id=2384587 (their
 ast-interpreter is faster than a byte code interpreter).

 Another solution would be to execute some method with the vm and other one
 with the ast-interpreter, but it is quite some work.


 2013/4/7 Alexandre Bergel alexandre.ber...@me.com
 Would it be possible to annotate the method with some checkpoints within
 the method? This should be fast enough I guess.

 Alexandre


 On Apr 6, 2013, at 10:35 AM, Clément Bera bera.clem...@gmail.com wrote:

  This is exactly that. The tree coverage tool is a subclass of
 AST-interpreter, which adding to the interpretation marks the nodes. And
 then I use this marking to color the source code. And I use as you said RB
 ast.
 
  This is why I implemented it in a few hours, I had already an
 AST-interpreter, so I've just created a quick subclass and a spec UI.
 
 
  2013/4/6 Frank Shearar frank.shea...@gmail.com
  So if you don't mind me being very loose with terminology, you
  interpret (RB) ASTs, and the act of interpreting marks the nodes in
  these ASTs, which you can then use to colour source?
 
  frank
 
  On 6 April 2013 11:00, Clément Bera bera.clem...@gmail.com wrote:
   Actually, it is quite different than Jejak.
  
   Implementation wise, Jejak used Opal so I guess it relies on bytecode
   modification to do its analysis where my tool relies on ast
 annotations.
  
   This implies some difference in features. It seems that Jejak record
 all
   calls, all values and all assignments in a method (which is byte code
 level
   feature), whereas I record for each ast node if it was interpreted or
 not
   (which is ast level feature). I guess there would be a little
 difference in
   the use cases.
  
  
   2013/4/6 Frank Shearar frank.shea...@gmail.com
  
   On 6 April 2013 07:47, Stéphane Ducasse stephane.duca...@inria.fr
 wrote:
  
   Clement built in a couple of hours the following nice branch
   analysecoverage tools :)
   It is dead slow but cool.
  
  
   By branch coverage tool do you mean Jejak?
  
   frank
  
  
  
  
  
   --
   Clément Béra
   Mate Virtual Machine Engineer
   Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
 
 
 
 
  --
  Clément Béra
  Mate Virtual Machine Engineer
  Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

 --
 _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
 Alexandre Bergel  http://www.bergel.eu
 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.







 --
 Clément Béra
 Mate Virtual Machine Engineer
 Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq


 --
 _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
 Alexandre Bergel  http://www.bergel.eu
 

[Pharo-project] new Cog VMs available

[Eliot Miranda]

at http://www.mirandabanda.org/files/Cog/VM/VM.r2714/

These fix quite a serious bug with the JIT that would cause crashes in
large images.

CogVM binaries as per VMMaker.oscog-eem.282/r2714

Change application name from Croquet to Squeak and change to green Cog
Squeak
icons.  Add accurate version info to the Windows exes (include SCCSID in
properties).

Add the SSLPlugin on mac and linux (won't link on old mingw; need to
update).

Cogit: Fix *HORRIBLE* yet ancient bug with the CogObjectRep.
Both CogObjectRepresentationForSqueakV3couldBeObject: 
CogObjectRepresentationForSqueakV3shouldAnnotateObjectReference:
used signed comparisons for oops and so once the heap size
pushes oops into the upper half of the address space constant
oops in machine code were no longer being updated by the GC.

StackInterpreter: rewrite the login for printing methods so that
printing the frame of a bad receiver won't seg fault.

Add primitivePathToUsing which mimics the PointerFinder and can hence be
used
to debug or verify it.

Remove unnecessary forceInterruptCheck in
NewObjectMemorybecome:with:twoWay:copyHash:.
(heartbeat does this for us).

Fix bug in assert in NewCoObjectMemoryrestoreHeaderOf:to:.

Slang:
Fix translation of to:by:do: loops so that the limit is not re-evaluated
on each iteration if it may have side-effects.

Include the correct AioPlugin (UnixAioPlugin)

Include SqueakSSLPlugin in the configurations.

Cogit:
Stop reporting EncounteredUnknownBytecode with an error message.

Fix slip in ceSICMiss: that didn't link new PIC if an MNU case.

Add pixel peeker prims to BitBltPlugin.
Minor signature changes to BitBltPlugin  HostWindowPlugin from
SmartSyntaxPluginGenerator bug fix.

-- 
best,
Eliot

Re: [Pharo-project] Reproducible VM crash when loading FFI

[Eliot Miranda]

Hi Guille,

thanks for this.  The problem is that Pharo's
recreateSpecialObjectsArray uses newCompactClassesArray to recreate the
compact classes array and on Cog that is not supported.  Cog caches the
compactClassesArray (specialObjectsArray at: 29) in every jitted method
prolog to reduce the time taken to derive the receiver's class in message
lookup.  The Pharo 2.0 code for recreating the specialObjectsArray can
therefore create a dangling pointer where the only reference to the old
compactClassesArray is in machine code, and the machine code GC doesn't
cope with there being roots in machine code.  Note that Cog also caches the
characterTable and class SmallInteger in machine code.

There are two solutions to this.
One would be to reuse the compactClassesArray (my recommendation).  So that
recreateSpecialObjectsArray looks like

...
An array of the 255 Characters in ascii order.
 Cog inlines table into machine code at: prim so do not regenerate it.
newArray at: 25 put: Character characterTable.
...
A 32-element array with up to 32 classes that have compact instances.
 Cog inlines table into machine code class lookup so do not regenerate it.
newArray at: 29 put: self compactClassesArray.
...

where compactClassesArray, like Character characterTable, answers the
existing object.

The second solution (rather hackish) is to void all machine code on
installing the new specialObjectsArray.  e.g.
recreateSpecialObjectsArray
Smalltalk recreateSpecialObjectsArray
 To external package developers:
 DO NOT OVERRIDE THIS METHOD.  *
If you are writing a plugin and need additional special object(s) for your
own use,
use addGCRoot() function and use own, separate special objects registry 
 The Special Objects Array is an array of objects used by the Squeak
virtual machine.
 Its contents are critical and accesses to it by the VM are unchecked, so
don't even
 think of playing here unless you know what you are doing.
 Replace the interpreter's reference in one atomic operation.
 Void machine code to avoid crashing Cog.
| newSpecialObjectsArray |
newSpecialObjectsArray := self newSpecialObjectsArray.
self specialObjectsArray becomeForward: newSpecialObjectsArray.
Smalltalk vm voidCogVMState


this is my fault for not ensuring recreateSpecialObjectsArray was properly
commented.  I had commented the inlining of Character table, but not the
inlining of the CompactClasses array. Apologies.

HTH,
Eliot

On Sat, Mar 23, 2013 at 10:19 AM, Guillermo Polito 
guillermopol...@gmail.com wrote:

 Hi!

 In my quest to crash the vm, i've found an ugly common case :(.
 I am trying to port the opendbx driver to 2.0, but I'm getting vm crashes
 when my configuration loads FFI :(. I updated my configuration to load
 version 1.7 of FFI (which I assume is the latest).

 I tried to do it in Pharo 2.0 with latest pharovm, and with eliot's Cog
 2701 from his website, failing in both cases.
 The snippet of code that gets a sistematic crash is:

 Gofer it
 smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver';
 package: 'ConfigurationOfOpenDBXDriver';
  load.
 ((Smalltalk at: #ConfigurationOfOpenDBXDriver) project version:#stable)
 load


 This snippet crashes always with a segmentation fault (at least the
 fifteen times i tried :), with several different output in the console...

 Surprisingly, if I load FFI alone and not from the OpenDBXDriver
 configuration, it loads well... :/

 So I'm deferring the OpenDBX port a bit longer :(

 Thanks!
 Guille




-- 
best,
Eliot

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

[Eliot Miranda]

On Thu, Mar 14, 2013 at 7:20 AM, Esteban Lorenzano esteba...@gmail.comwrote:


 On Mar 13, 2013, at 7:11 PM, Eliot Miranda eliot.mira...@gmail.com
 wrote:



 On Tue, Mar 12, 2013 at 7:54 PM, Igor Stasenko siguc...@gmail.com wrote:

 On 12 March 2013 19:44, Eliot Miranda eliot.mira...@gmail.com wrote:
 

  3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons
 and
  c) new FileSystem primitives.
  a) is cool, but I don't like the x86 specificity.  I want a
 cross-platform
  FFI, so I'm not excited enough to include NB in my port.

 Just let me remind you that (x86 specificity) is completely on image side.
 The VM side changes are minimal and 100% not platform specific.
 Making NB image-side implementation platform-unspecific is another story..
 but as i said before i see no reason to do it unless there's a version
 of Cog which runs
 on some other platform :)


 I understand that.  I think Squeak should provide a platform-independent
 FFI at the image level.



 There is plans and some work started on getting there, by making a
 platform-neutral low-level
 DSL, which can be used for generating native code.


 This is called RTL ;)


 I never hear about it... you mean
 http://en.wikipedia.org/wiki/Register_transfer_language ?
 If so, looks interesting :)


Yes.  RTL is essentially an assembler for an abstract machine with readable
names for registers.  Arguably the Cog back-end assembler is an RTL.  It
has abstract registers (ReceiverResultReg, ClassReg etc), and abstract
operations (e.g. MoveR:R:).  To do marshalling you need only define
argument registers (floating-point and integer, an empty set on the x86),
return registers, the stack pointer, and maybe the frame pointer, plus a
basic set of data manipulation instructions.  Then either define these as
numeric constants so that the JIT interprets sequences of numbers, or
strings, so that the JIT uses string matching (the former is of course
faster and slimmer).  The JIT maps these abstract instructions and register
names into concrete machine code and register numbers.

Note that the RTL still has platform-specific constructs, e.g. a LinkReg is
valid on RISCs but meaningless on x86, and the ABI-to-RTL compiler has all
the knowledge about the format of outgoing calls, what kinds of registers
are available (address, data, floating-point, etc).  But it does not have
to do the final assembly step, fixing up branches etc. This is low-level
work the JIT already does and needs to do itself because it knows at what
addresses code is generated at.

P.S. that wikipedia page is rather poor.  Another example other than GCC's
is Ralph Johnson's and Carl McConnell's The *RTL* System: A Framework for
Code 
Optimizationhttp://www.google.com/url?sa=trct=jq=ralph%20johnson%20rtlsource=webcd=3ved=0CEQQFjACurl=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fsummary%3Fdoi%3D10.1.1.50.6632ei=Hw9CUcWyGJKkqQGj3YGAAwusg=AFQjCNGoQxB5uhsnqCm-yUr9_ihxu2iODAsig2=lex4YodEuPolzf3ezZ8t8gbvm=bv.43287494,d.aWM
.


 Esteban




 --
 Best regards,
 Igor Stasenko.




 --
 best,
 Eliot





-- 
best,
Eliot

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

[Eliot Miranda]

On Tue, Mar 12, 2013 at 7:54 PM, Igor Stasenko siguc...@gmail.com wrote:

 On 12 March 2013 19:44, Eliot Miranda eliot.mira...@gmail.com wrote:
 

  3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons
 and
  c) new FileSystem primitives.
  a) is cool, but I don't like the x86 specificity.  I want a
 cross-platform
  FFI, so I'm not excited enough to include NB in my port.

 Just let me remind you that (x86 specificity) is completely on image side.
 The VM side changes are minimal and 100% not platform specific.
 Making NB image-side implementation platform-unspecific is another story..
 but as i said before i see no reason to do it unless there's a version
 of Cog which runs
 on some other platform :)


I understand that.  I think Squeak should provide a platform-independent
FFI at the image level.



 There is plans and some work started on getting there, by making a
 platform-neutral low-level
 DSL, which can be used for generating native code.


This is called RTL ;)



 --
 Best regards,
 Igor Stasenko.




-- 
best,
Eliot

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

[Eliot Miranda]

On Tue, Mar 12, 2013 at 2:57 AM, Esteban Lorenzano esteba...@gmail.comwrote:

 We use an automated building method that tries to be exactly the same in
 each platform. We decided not to create bundles but dylibs because bundles
 are mac-specific stuff and .dylibs same (but for mac) as .so and .dll.
 Our process builds the vm, the plugins and the third party libraries as an
 all-in-one. Eliot builds are hand made, and when there is a process (like
 the autotool for unix builds), they are platform-specific.


That mine are hand-builkt is a straw man. They're not.  I kick off the
builds by hand but everything is scripted and reproducible, and included in
the generated source.  I don't (yet) have access to Jenkins for all three
platforms.  But the VMs at Cadence are now all built via Jenkins (thanks to
Bob Westergaard).  What's different is a fork.

1. Cog includes the set of plugins that came from Qwaq/Teleplace plus the
plugin needed to develop the VM (the x86 simulator BochsIA32Plugin).  Pharo
uses the set of plugins it has chosen (several of the same plugins are
internal to the Cog VM, e.g. UUIDPlugin is internal in Cog).

2. Pharo uses CMake driven from Smalltalk; I'm too lazy to move, so
automake is used (one in a blue moon) on linux, and hand-crafted makefiles
on Mac and Windows (that don't change much).  The Pharo way is better
(although I find CMake as incomprehensible and arbitrary as automake), but
both Cog and Pharo have predictable C make systems.

3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons and
c) new FileSystem primitives.
a) is cool, but I don't like the x86 specificity.  I want a cross-platform
FFI, so I'm not excited enough to include NB in my port.
b) is useful (I fixed the implementation of ephemerons for VisualWorks done
by someone else a while back, and I understand them well), but I don't like
Igor's implementation.  IMO the ephemeronness of an object needs to be
reflected in its format field (the 4 bit type field in every object), not
found by indirecting through the class, which is hairy in the current GC
and slow.  I've proposed an alternative and Igor is I think in agreement,
but we have to find the time to implement it.
 c) I have to find time to port.  Its a no-brainer.


 TL;DR: Is easier for us to build all the vm stuff in an unified way :)

 Esteban

 On Mar 12, 2013, at 10:49 AM, p...@highoctane.be p...@highoctane.be
 wrote:

  Eliot's CogVM vs PharoVM on Mac application contents. Quite different.
 
  And worth some explanations :-) Why is it that way?
 
  Phil
 
  2013/3/12 Stephan Eggermont step...@stack.nl:
  It would be good to have a parallel job, but the problem is that you
 will
  get a message saying that the VM is too old for the Pharo 2.0 image.
 
  I started the latest MOOSE image on Eliots latest VM on mac.
  It still has the 'old vm' warning.
  Adding a monticello repository (directory) doesn't work.
  Tests are still running
 
  Stephan
 
 
  2013-03-12_10-43-37.png





-- 
best,
Eliot

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

[Eliot Miranda]

On Tue, Mar 12, 2013 at 12:01 PM, Esteban Lorenzano esteba...@gmail.comwrote:


 On Mar 12, 2013, at 7:44 PM, Eliot Miranda eliot.mira...@gmail.com
 wrote:



 On Tue, Mar 12, 2013 at 2:57 AM, Esteban Lorenzano esteba...@gmail.comwrote:

 We use an automated building method that tries to be exactly the same in
 each platform. We decided not to create bundles but dylibs because bundles
 are mac-specific stuff and .dylibs same (but for mac) as .so and .dll.
 Our process builds the vm, the plugins and the third party libraries as
 an all-in-one. Eliot builds are hand made, and when there is a process
 (like the autotool for unix builds), they are platform-specific.


 That mine are hand-builkt is a straw man. They're not.  I kick off the
 builds by hand but everything is scripted and reproducible, and included in
 the generated source.  I don't (yet) have access to Jenkins for all three
 platforms.  But the VMs at Cadence are now all built via Jenkins (thanks to
 Bob Westergaard).  What's different is a fork.


 my bad... I thought it was hand made, I'm sorry. Good to know that it
 isn't.


 1. Cog includes the set of plugins that came from Qwaq/Teleplace plus the
 plugin needed to develop the VM (the x86 simulator BochsIA32Plugin).  Pharo
 uses the set of plugins it has chosen (several of the same plugins are
 internal to the Cog VM, e.g. UUIDPlugin is internal in Cog).


 yes, as I said there is minimal difference between internal and
 external... just a a matter of taste if you want :)


 2. Pharo uses CMake driven from Smalltalk; I'm too lazy to move, so
 automake is used (one in a blue moon) on linux, and hand-crafted makefiles
 on Mac and Windows (that don't change much).  The Pharo way is better
 (although I find CMake as incomprehensible and arbitrary as automake), but
 both Cog and Pharo have predictable C make systems.


 yes, I agree that cmake is as incomprehensible as autoconf... a terrible
 pain when you need to touch them directly... that´s why we try to use the
 CMakeMaker package, who helps (but not completely) to make the task less
 painful.


 3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons and
 c) new FileSystem primitives.
 a) is cool, but I don't like the x86 specificity.  I want a cross-platform
 FFI, so I'm not excited enough to include NB in my port.
 b) is useful (I fixed the implementation of ephemerons for VisualWorks
 done by someone else a while back, and I understand them well), but I don't
 like Igor's implementation.  IMO the ephemeronness of an object needs to be
 reflected in its format field (the 4 bit type field in every object), not
 found by indirecting through the class, which is hairy in the current GC
 and slow.  I've proposed an alternative and Igor is I think in agreement,
 but we have to find the time to implement it.
  c) I have to find time to port.  Its a no-brainer.


 I do not consider pharo a fork. I think is wrong to think on it like a
 separated development. We put some effort on top of your own effort to
 match other requirements (like NB, branding, allow some experiments, etc.),
 but in essence is the same cog... we just change the cover :)
 Most of the changes are now based on: NB, the Cocoa branch and some
 plugins not yet integrated... I hardly would consider that a fork (and we
 try not to fork in purpose: is dumb to divide the work of the few ppl who
 work on the vm level in our community).


Yes, I agree.  I didn't choose my words carefully enough.  It is a version
of Cog, just as the one I build is the Croquet version (soon to be a Squeak
version).

But it would be nice if there was more agreement on the format of Smalltalk
getSystemAttribute: 1009.  This is a useful attribute and nice if it were
parsed by the Pharo image code.


Pharo however has a different vision than other communities in some points,
 specifically about the plugins and its place: the plugins should be moved
 to inside the image as much as they can (that's why NB is so important for
 us). The idea is to allow the community to participate in maintaining the
 plugins and keep the vm programmers focused on... well, vm stuff :)

 Esteban



 TL;DR: Is easier for us to build all the vm stuff in an unified way :)

 Esteban

 On Mar 12, 2013, at 10:49 AM, p...@highoctane.be p...@highoctane.be
 wrote:

  Eliot's CogVM vs PharoVM on Mac application contents. Quite different.
 
  And worth some explanations :-) Why is it that way?
 
  Phil
 
  2013/3/12 Stephan Eggermont step...@stack.nl:
  It would be good to have a parallel job, but the problem is that you
 will
  get a message saying that the VM is too old for the Pharo 2.0 image.
 
  I started the latest MOOSE image on Eliots latest VM on mac.
  It still has the 'old vm' warning.
  Adding a monticello repository (directory) doesn't work.
  Tests are still running
 
  Stephan
 
 
  2013-03-12_10-43-37.png





 --
 best,
 Eliot





-- 
best,
Eliot

[Pharo-project] new Cog VMs available

[Eliot Miranda]

at http://www.mirandabanda.org/files/Cog/VM/VM.r2701/.

CogVM binaries as per VMMaker.oscog-eem.272/r2701.

Fix unknownBytecode processing to leave pc at unknown bytecode.
Fix case of process switch to an interior frame.
Fix some assert function signatures in the stack vm.
Use symbols for types instead of strings in stack page funcs.

Fix the become issue where methods that are identical are failing
the code test because their penultimate literals are different objects.
Add a flag cmUsesPenultimateLit to jitted methods, stealing bits
from stackCheckOffset (which was way larger than needed).
Shrink stackCheckOffset to 12 bits (still an order of magnitude larger
than needed) and add an error check on assigning it.
Also add a check for max method size (2^16-1 bytes) and refuse to
jit a method that generates too much code.
When comparing code, use the cmUsesPenultimateLit flag to decide
if comparison includes penultimate lit or not.

This is mildly insane, but the VM really doesn't know about the
penultimate literal and it shouldn't depend on knowing it can be
ignored.  Note that the CoInterpreter knows about the last literal;
it uses this in supersends.  With this hack, Pharo's condenseSources
works.
-- 
best,
Eliot

Re: [Pharo-project] VM Crashes

[Eliot Miranda]

List,

I hope you realize I'm motivated to investigate VM crashes.
Esteban reports that the VM is now more stable w.r.t. becomeForward:
after I debugged load cases a couple of week ago.  But I could do with
some help.  It really helps to be provided with an image that
reproduces the bug in start-up.  e.g. evaluating a doit that saves and
then invokes crashing code:

  Smalltalk saveAs: 'crash'.
  Gofer it
  url: 'http://www.squeaksource.com/MetacelloRepository';
  package: 'ConfigurationOfFFI';
  load.
(Smalltalk at: #ConfigurationOfFFI) project stableVersion load.

This saves me a lot of time.  I have a day job that does not pay me to
investigate Cog crashes.  Your help is most appreciated.


On Fri, Mar 8, 2013 at 8:14 AM, Camillo Bruni camillobr...@gmail.com wrote:

 To join in again, my regression tests still seem to fail loading.
 So it looks like a similar effect as what sven experiences!

 https://ci.inria.fr/pharo/job/Pharo-2.0-Regression-Tests/VM=PharoVM,label=mac/110/console

--
best,
Eliot

Re: [Pharo-project] VM Crashes

[Eliot Miranda]

On Thu, Mar 7, 2013 at 9:05 AM, Jan Vrany jan.vr...@fit.cvut.cz wrote:

 On 07/03/13 15:58, Sven Van Caekenberghe wrote:

 I am getting crazy, it seems to be pretty random, sometimes it works,
 most of the time it doesn't.


 Well, if it sometimes happen and sometimes not and on other machines
 the same binary works like a charm, I would say this is due to a
 memory corruption - but you probably know that already :-)

 The crash in #becomeForward: is likely as it scans whole memory
 and sooner or later, it hit the corrupt object. So I think the
 #becomeForward: is probably not the bad guy here.


We know what the bug is; attempting to become jitted methods.  I think I
have a fix.  I did two versions of it recently.  Esteban is trying to get
people to try and reproduce the crash with the latest VM.  I *think* can
tell Sven's crash above is not using the latest VM because it is crashing
with a segmentation fault instead of exiting with an error message.  I
expect the VM to abort with an error message that reads either
attempt to become two cogged methods
or
attempt to become cogged method into different method





 On 07 Mar 2013, at 16:40, Esteban Lorenzano esteba...@gmail.com
 mailto:esteba...@gmail.com wrote:

  vm version?



 On both 32 and 64 bit...

  On Mar 7, 2013, at 4:35 PM, Sven Van Caekenberghe s...@stfx.eu
 mailto:s...@stfx.eu wrote:


 On 07 Mar 2013, at 15:31, Sven Van Caekenberghe s...@stfx.eu
 mailto:s...@stfx.eu wrote:

  I am still investigating, but it seems things changed in the Ubuntu
 universe regarding ia32-libs on 64 bit (it does no longer exist).
 Maybe that is a factor as well, I am not sure.


 I just installed a fresh 64-bit Ubuntu 12.10 Desktop in VirtualBox
 and tried my build there.

 sudo apt-get install ia32-libs

 is like a virtual package now that installs :i386 versions of already
 installed libraries (or something like that).

 Anyway, the VM worked but crashed when doing my build, again in
 #becomeForward:

 So it looks like is related to 32/64 bit differences.

 What kind of Linux machines are the build slaves in the CI
 infrastructure ?

 Sven


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










-- 
best,
Eliot

Re: [Pharo-project] VM Crashes

[Eliot Miranda]

I seem to be talking to thin air.  If you would use an up-to-date VM your
crashes would disappear.  This bug was fixed this last week.  You are using
a VM from December of last year.  Of course if you don't want to fix your
bug lease continue to ignore anything I might have to say.

On Thu, Mar 7, 2013 at 11:09 AM, Paul DeBruicker pdebr...@gmail.com wrote:

 EstebanLM wrote
  Sven, I think you do not have the last one... it should say Jenkins
 build
  #14533 someplace there...
  That probably will not change anything, but I want to be sure :)
 
  Esteban


 I'm having the same problem (intermittent crashes when loading code into
 Pharo2 with #becomeForward:).  I'm loading Seaside3.1 using an image and VM
 I downloaded today with this script:

 curl http://pharo.gforge.inria.fr/ci/script/ciPharo20CogVM.sh | bash


 I've attached the crash.dmp  crash.dmp
 http://forum.world.st/file/n4675599/crash.dmp

 It seems to me that the script ciPharo20CogVM.sh may not be downloading the
 VM you intend it to. Is that possible?  If I do

 ./vm.sh -version I get:

 paul@paul-laptop:~/pharo/p2$ ./vm.sh -version
 3.9-7 #1 Wed Dec 12 16:08:04 CET 2012 gcc 4.6.3
 CoInterpreter VMMaker-oscog-EstebanLorenzano.166 uuid:
 5773fcb9-2982-4507-8a9e-4308ec33731e Dec 12 2012
 StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.166 uuid:
 5773fcb9-2982-4507-8a9e-4308ec33731e Dec 12 2012
 git://gitorious.org/cogvm/blessed.git Commit:
 452863bdfba2ba0b188e7b172e9bc597a2caa928 Date: 2012-12-07 16:49:46 +0100
 By:
 Esteban Lorenzano esteba...@gmail.com Jenkins build #5922
 Linux pharo-linux64 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45 UTC
 2012 x86_64 x86_64 x86_64 GNU/Linux
 plugin path: /home/paul/pharo/p2/vm/ [default: /home/paul/pharo/p2/vm/]




 If I change to the vm directory and get a directory listing I get:

 paul@paul-laptop:~/pharo/p2/vm$ ls -latr
 total 39316
 -rw-r--r-- 1 paul paul 16235372 Oct 19  2009 PharoV10.sources
 drwxrwxr-x 2 paul paul 4096 Sep 30 03:52 __MACOSX
 -rwxrwxr-x 1 paul paul34420 Dec 12 07:07 libFT2Plugin.so
 -rwxrwxr-x 1 paul paul34639 Dec 12 07:08 libSqueakFFIPrims.so
 -rwxrwxr-x 1 paul paul71180 Dec 12 07:08 libB3DAcceleratorPlugin.so
 -rwxrwxr-x 1 paul paul21929 Dec 12 07:08 libSqueakSSL.so
 -rwxrwxr-x 1 paul paul12230 Dec 12 07:08 libInternetConfigPlugin.so
 -rwxrwxr-x 1 paul paul14461 Dec 12 07:08 vm-display-null
 -rwxrwxr-x 1 paul paul  1300278 Dec 12 07:08 CogVM
 -rwxrwxr-x 1 paul paul 7773 Dec 12 07:08 vm-sound-null
 -rwxrwxr-x 1 paul paul28640 Dec 12 07:08 vm-sound-ALSA
 -rwxrwxr-x 1 paul paul   121415 Dec 12 07:08 vm-display-X11
 -rw-r--r-- 1 paul paul 22239552 Mar  4 06:14 PharoV20.sources
 drwxrwxr-x 3 paul paul 4096 Mar  7 06:58 .
 drwxrwxr-x 4 paul paul 4096 Mar  7 11:00 ..



 Where do I get the correct VM that should output the error messages Eliot
 mentions below?


 Thanks

 Paul



 --
 View this message in context:
 http://forum.world.st/VM-Crashes-tp4675526p4675599.html
 Sent from the Pharo Smalltalk mailing list archive at Nabble.com.




-- 
best,
Eliot

Re: [Pharo-project] VM Crashes

[Eliot Miranda]

On Thu, Mar 7, 2013 at 2:23 PM, Sven Van Caekenberghe s...@stfx.eu wrote:

 Hi Eliot,

 On 07 Mar 2013, at 23:12, Eliot Miranda eliot.mira...@gmail.com wrote:

  I seem to be talking to thin air.  If you would use an up-to-date VM
 your crashes would disappear.  This bug was fixed this last week.  You are
 using a VM from December of last year.  Of course if you don't want to fix
 your bug lease continue to ignore anything I might have to say.

 I tried using your latest cog vm, but the Pharo 2.0 image side check
 complained:

 checkVMVersion
 Display a warning if the VM is too old
 | displayError |
 displayError := [ ^ self inform: 'Your VM is too old for this
 image. Please download the latest VM.' ].
 [(VirtualMachine interpreterSourceDate  '2012-07-08+2:00' asDate)
 ifFalse: displayError
 ] on: Error do: [ :e| displayError value ].

 I was unsure if this was a real problem or not ?
 Maybe it just fails to extract the date ?


Yes.  It's using a primitive my Cog VMs don't have. :(  In any case,
Esteban has (I believe) updated the Pharo VM with the relevant fixes.  So
the solution is to use the latest Pharo VM.

Apologies for my intemperate tone.  IO notied after I hit send that you'd
seen my mention of fixed VMs earlier.


 interpreterSourceDate
 Return the date of changes given by `self
 interpreterSourceVersion`
 | dateString parts |

 dateString := (self interpreterSourceVersion splitOn: 'Date: ')
 second.

 dateString first isDigit
 ifTrue: [
 most probably the date is in ISO 8601 Format
 ^ dateString asDateAndTime ].

 Otherwise assume the old format: DDD MMM DD HH:MM:SS  +
 ...
 parts := dateString substrings first: 6.
 create a more reasonable string..
 dateString := String streamContents: [ :s |
 s
 nextPutAll: (parts at: 5 ); space; year
 nextPutAll: (parts at: 2 ); space; month name
 nextPutAll: (parts at: 3 ); space; day of month
 nextPutAll: (parts at: 4 ); space; time
 nextPutAll: (parts last); spacetimezone].
 ^ dateString asDateAndTime

 Sven





-- 
best,
Eliot

[Pharo-project] new Cog VMs available

[Eliot Miranda]

at http://www.mirandabanda.org/files/Cog/VM/VM.r2697/

CogVM binaries as per VMMaker.oscog-eem.270/r2697

Fix the become issue where methods that are identical are failing
the code test because their penultimate literals are different objects.
Add a flag cmUsesPenultimateLit to jitted methods, stealing bits
from stackCheckOffset (which was way larger than needed).
Shrink stackCheckOffset to 12 bits (still an order of magnitude larger
than needed) and add an error check on assigning it.
Also add a check for max method size (2^16-1 bytes) and refuse to
jit a method that generates too much code.
When comparing code, use the cmUsesPenultimateLit flag to decide
if comparison includes penultimate lit or not.

This is mildly insane, but the VM really doesn't know about the penultimate
literal and it shouldn't depend on knowing it can be ignored.  Note that the
CoInterpreter knows about the last literal; it uses this in supersends.
With this hack, Pharo's condenseSources works.

Fix bug in primitiveClone/cloneContext: that causes the copy to be a word
short.
Use isPointerNonInt: and isContextNonInt: in a few places.

Implement unknownBytecode.  Send unknownBytecode to the activeContext on
unknown bytecode if the selector is in the specialObjectsArray.

Fix page size bug in platforms/Cross/vm/sqHeapMap.c.

-- 
best,
Eliot

Re: [Pharo-project] fast #becomeForward: crashes without PharoV10.sources

[Eliot Miranda]

On Tue, Feb 26, 2013 at 4:13 AM, Igor Stasenko siguc...@gmail.com wrote:

 we should reafctor the code for changing the method's trailer (source
 pointer) to
 avoid using #become: at all.
 this won't deal with VM bug per se, but at least prevent it from
 triggering.


No, that makes little sense.  Instead provide me with a reproducible case
and I'll fix it quickly.  I fixed the case form last week in one day.
 Become: should work, but I can't fix things if I can't reproduce the bugs.
 So please take the time to produce an image that crashes from start-up.



 On 25 February 2013 23:26, Esteban Lorenzano esteba...@gmail.com wrote:
  he is talking about some chrashes that happens fast, when you do become
 :)
 
  nothing about fast become
 
  On Feb 25, 2013, at 10:26 PM, Mariano Martinez Peck 
 marianop...@gmail.com
  wrote:
 
  mmm what do you mean by fast becomeForward: ?
 
  On Mon, Feb 25, 2013 at 1:01 PM, Camillo Bruni camillobr...@gmail.com
  wrote:
 
  While setting up the new multi platform VM tests I saw that the tests
 fail
  extremely quickly
  when there are not PharoV10.sources available.
 
  It is still our know #becomeForward: but on CompiledMethods, but I just
  want to share that.
 
 
 
 
  --
  Mariano
  http://marianopeck.wordpress.com
 
 



 --
 Best regards,
 Igor Stasenko.




-- 
best,
Eliot

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

[Eliot Miranda]

On Mon, Feb 25, 2013 at 5:23 AM, Marcus Denker marcus.den...@inria.frwrote:


 On Feb 25, 2013, at 2:18 PM, Pavel Krivanek pavel.kriva...@gmail.com
 wrote:

  Why doesn't it work in CogVM?

 because we become: methods when installing a new trailer and cog does not
 support
 become: on active methods.


It does now.  I fixed this last week.


  Is condenseChanges ok now too?
 
 I personally think we should not care. In 3.0 we really need get rid of
 this overly horrible
 .sources and .changes monster for something trivially simplistic.

 We saved *a lot* on our Moore's Bank account the last years… at some point
 it is time
 to invest that. Keep in mind that available RAM will double again until we
 release 3.0…

 Marcus





-- 
best,
Eliot

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

[Eliot Miranda]

On Mon, Feb 25, 2013 at 2:25 PM, Esteban Lorenzano esteba...@gmail.comwrote:


 On Feb 25, 2013, at 10:01 PM, Eliot Miranda eliot.mira...@gmail.com
 wrote:



 On Mon, Feb 25, 2013 at 5:23 AM, Marcus Denker marcus.den...@inria.frwrote:


 On Feb 25, 2013, at 2:18 PM, Pavel Krivanek pavel.kriva...@gmail.com
 wrote:

  Why doesn't it work in CogVM?

 because we become: methods when installing a new trailer and cog does not
 support
 become: on active methods.


 It does now.  I fixed this last week.


 no, it still does not works completely... but now it has a clear message
 and exit, instead a crash :)


reproducible test case, please :)





  Is condenseChanges ok now too?
 
 I personally think we should not care. In 3.0 we really need get rid of
 this overly horrible
 .sources and .changes monster for something trivially simplistic.

 We saved *a lot* on our Moore's Bank account the last years… at some
 point it is time
 to invest that. Keep in mind that available RAM will double again until
 we release 3.0…

 Marcus





 --
 best,
 Eliot





-- 
best,
Eliot

Re: [Pharo-project] Stack VM problem

[Eliot Miranda]

That's not a VM bug.  1008 returns the Cogit version.  The StackVM
doesn't include a JIT.  hence no Cogit version.  The bug is in
VirtualMachine classversion.

On Sat, Feb 23, 2013 at 7:03 AM, Sean P. DeNigris s...@clipperadams.com wrote:
 stack-mac-3.zip (latest on gforge)
 VirtualMachine getSystemAttribute: 1008 = nil

 UndefinedObject(Object)doesNotUnderstand: #do:
 WriteStream(Stream)nextPutAll:
 WriteStreamnextPutAll:
 VirtualMachine classversion in Block: [:s | ...

 Should VM issues be opened in the Pharo tracker, cog, or somewhere else?

 Cheers,
 Sean



 --
 View this message in context: 
 http://forum.world.st/Stack-VM-problem-tp4671675.html
 Sent from the Pharo Smalltalk mailing list archive at Nabble.com.




-- 
best,
Eliot

Re: [Pharo-project] A matter with Delays

[Eliot Miranda]

On Thu, Feb 21, 2013 at 3:28 AM, Igor Stasenko siguc...@gmail.com wrote:
 Hi.

 There is one thing which is IMO an over-engineering artifact:
 - when system goes down (image shutdown), all currently scheduled
 delays are saved
 and then when image starting up they are rescheduled again to keep
 waiting what time is left for delay..

Right now one says Delay forMilliseconds: n etc.  That's clearly a
duration.  An API which said Delay until: aTime is different, and
could be added to the current API easily.

One good reason for keeping the current behaviour is profiling image
shutdown and startup.  The current MessageTally is slightly broken in
this regard but I fixed it at Cadence to profile our start-up
slowness.

So please consider carefully throwing this behaviour away.  I at least
find it quite useful.

 But the problem is that it does not takes into account the total time
 an image was frozen, and the requirement is quite ambiguous:

  - if you put a process on a delay for 5 minutes, then immediately
 save image, and then restart it 10 minutes (or 1 year) after,
 should this delay keep waiting for 4 +x seconds which is left? Or
 should we consider this delay as utterly expired?
 (and as you can see, the answer is different, if we counting time
 using real, physical time, or just image uptime).

 And why counting image uptime? Consider use cases, like connection
 timeout.. it is all about
 real time , right here , right now.. will it matter to get socket
 connection timeout error when you restart some image 1 year after?
 Please, give me a scenario, which will illustrate that we cannot live
 without it and should count image uptime for delays, because i can't
 find one.

 If not, then to my opinion, and to simplify all logic inside delay
 code, i would go straight and declare following:
  - when new image session starts, all delays, no matter for how long
 they are scheduled to wait are considered expired (and therefore all
 waiting processes
 is automatically resumed).

 Because as tried to demonstrate, the meaning of delay which spans over
 multiple image sessions is really fuzzy and i would be really
 surprised to find a code
 which relies on such behavior.

 This change will also can be helpful with terminating all processes
 which were put on wait for too long (6304550344559763 milliseconds) by
 mistake or such.


 --
 Best regards,
 Igor Stasenko.




-- 
best,
Eliot

Re: [Pharo-project] Fwd: A question about lookup and message reification

[Eliot Miranda]

Hi Stef,

On Wed, Feb 13, 2013 at 11:40 AM, Stéphane Ducasse 
stephane.duca...@inria.fr wrote:

 I repost the mail to the mailing-list since I do not see it in the vm-dev


did you post to vm-dev?



 Stef


 Hi

 I was reading the following method in the VM code and I have a couple of
 questions:

 - I do not understand why lookupMethodInClass: may return a class. I was
 thinking that it would return a method.


It doesn't matter what it returns as it's return value is always ignored.
 It assigns to newMethod.  I suspect it returns currentClass because a) the
return type was always sqInt because Slang didn't support void functions,
and b) currentClass is a value in hand so probably in a register and hence
cheap to return.


 - what is the invariant?
 that currentclass always point to the currently looked up class and
 newMethod is the found method?


The input arguments are messageSelector, argumentCount and its argument,
class.  The VM suffers somewhat from being cluttered with global variables,
which is I think a legacy of the blue-book specification (the Smalltalk
code that was used to implement Interpreter in VMMaker) being derived from
the Alto and Dorado implementations in microcode.  It would be nicer if
there were fewer variables, but e.g. supplying argumentCount as a parameter
throughout all the message handling routines can be difficult, especially
when things like perform: and MNU change the argumentCount during message
send.

- why lookupMethodFor: selector InDictionary: dictionary is defined in
 StackInterpreter but never used
 only in CoInterpreter?


Well, it belongs in StackInterpreter and could be used in the other lookup
methods.  I was probably considering rewriting the other lookup routines to
use  lookupMethodFor: InDictionary: but didn't get round to it.


 Thanks


 lookupMethodInClass: class
 | currentClass dictionary found |
 inline: false
 self assert: class ~= objectMemory nilObject.
 currentClass := class.
 [currentClass ~= objectMemory nilObject]
 whileTrue:
 [dictionary := objectMemory fetchPointer: MethodDictionaryIndex ofObject:
 currentClass.

 *** trick with the cannotInterpret ***
 dictionary = objectMemory nilObject ifTrue:
 [MethodDict pointer is nil (hopefully due a swapped out stub)
 -- raise exception #cannotInterpret:.
 self createActualMessageTo: class.
 messageSelector := objectMemory splObj: SelectorCannotInterpret.
 self sendBreak: messageSelector + BaseHeaderSize
 point: (objectMemory lengthOf: messageSelector)
 receiver: nil.
 ^self lookupMethodInClass: (self superclassOf: currentClass)].
 *** trick with the cannotInterpret end ***

 found := self lookupMethodInDictionary: dictionary.
 found ifTrue: [^currentClass].
 ^

 currentClass := self superclassOf: currentClass].

 Could not find #doesNotUnderstand: -- unrecoverable error.
 messageSelector = (objectMemory splObj: SelectorDoesNotUnderstand) ifTrue:
 [self error: 'Recursive not understood error encountered'].

 Cound not find a normal message -- raise exception #doesNotUnderstand:
 self createActualMessageTo: class.
 messageSelector := objectMemory splObj: SelectorDoesNotUnderstand.
 self sendBreak: messageSelector + BaseHeaderSize
 point: (objectMemory lengthOf: messageSelector)
 receiver: nil.
 ^self lookupMethodInClass: class


 if (found) {
 return currentClass;
 }


 static sqInt
 lookupMethodInClass(sqInt class)
 {
 // StackInterpreter#lookupMethodInClass:   DECL_MAYBE_SQ_GLOBAL_STRUCT
 sqInt currentClass;
 sqInt dictionary;
 sqInt found;
 sqInt header;
 sqInt index;
 sqInt length;
 sqInt mask;
 sqInt methodArray;
 sqInt nextSelector;
 sqInt sz;
 sqInt wrapAround;

 assert(class != (nilObject()));
 currentClass = class;
 while (currentClass != GIV(nilObj)) {
 dictionary = longAt((currentClass + BaseHeaderSize) +
 (MethodDictionaryIndex  ShiftForWord));
 if (dictionary == GIV(nilObj)) {

 /* ifTrue: */

 createActualMessageTo(class);
 GIV(messageSelector) = longAt((GIV(specialObjectsOop) + BaseHeaderSize) +
 (SelectorCannotInterpret  ShiftForWord));
 sendBreakpointreceiver(GIV(messageSelector) + BaseHeaderSize,
 lengthOf(GIV(messageSelector)), null);
 return lookupMethodInClass(longAt((currentClass + BaseHeaderSize) +
 (SuperclassIndex  ShiftForWord)));
 }
 /* begin lookupMethodInDictionary: */
 /* begin fetchWordLengthOf: */
 /* begin sizeBitsOf: */
 header = longAt(dictionary);
 sz = ((header  TypeMask) == HeaderTypeSizeAndClass
 ? (longAt(dictionary - (BytesPerWord * 2)))  LongSizeMask
 : header  SizeMask);
 length = ((usqInt) (sz - BaseHeaderSize))  ShiftForWord;
 mask = (length - SelectorStart) - 1;

 /* messageSelector */

 index = SelectorStart + (mask  (((GIV(messageSelector)  1)
 ? (GIV(messageSelector)  1)
 : (((usqInt) (longAt(GIV(messageSelector  HashBitsOffset) 
 HashMaskUnshifted)));
 wrapAround = 0;
 while (1) {
 nextSelector = longAt((dictionary + BaseHeaderSize) + (index 
 ShiftForWord));
 if (nextSelector == 

Re: [Pharo-project] Fwd: A question about lookup and message reification

[Eliot Miranda]

On Wed, Feb 13, 2013 at 12:11 PM, Eliot Miranda eliot.mira...@gmail.comwrote:

 Hi Stef,

 On Wed, Feb 13, 2013 at 11:40 AM, Stéphane Ducasse 
 stephane.duca...@inria.fr wrote:

 I repost the mail to the mailing-list since I do not see it in the vm-dev


 did you post to vm-dev?



 Stef


 Hi

 I was reading the following method in the VM code and I have a couple of
 questions:

 - I do not understand why lookupMethodInClass: may return a class. I was
 thinking that it would return a method.


 It doesn't matter what it returns as it's return value is always ignored.
  It assigns to newMethod.  I suspect it returns currentClass because a) the
 return type was always sqInt because Slang didn't support void functions,
 and b) currentClass is a value in hand so probably in a register and hence
 cheap to return.


 - what is the invariant?
  that currentclass always point to the currently looked up class and
 newMethod is the found method?


 The input arguments are messageSelector, argumentCount and its argument,
 class.  The VM suffers somewhat from being cluttered with global variables,
 which is I think a legacy of the blue-book specification (the Smalltalk
 code that was used to implement Interpreter in VMMaker) being derived from
 the Alto and Dorado implementations in microcode.  It would be nicer if
 there were fewer variables, but e.g. supplying argumentCount as a parameter
 throughout all the message handling routines can be difficult, especially
 when things like perform: and MNU change the argumentCount during message
 send.


and so argumentCount must be the number of objects on the stack minus one,
messageSelector must be an object (any object).  The argument class must
be a behavior-like object that is on a list of behavior-like objects linked
through the superclass field that terminates with nil.  Each object on the
chain must have either nil or a method dictionary-like object in its method
dictionary.


 - why lookupMethodFor: selector InDictionary: dictionary is defined in
 StackInterpreter but never used
 only in CoInterpreter?


 Well, it belongs in StackInterpreter and could be used in the other lookup
 methods.  I was probably considering rewriting the other lookup routines to
 use  lookupMethodFor: InDictionary: but didn't get round to it.


 Thanks


 lookupMethodInClass: class
 | currentClass dictionary found |
 inline: false
  self assert: class ~= objectMemory nilObject.
 currentClass := class.
 [currentClass ~= objectMemory nilObject]
  whileTrue:
 [dictionary := objectMemory fetchPointer: MethodDictionaryIndex ofObject:
 currentClass.

  *** trick with the cannotInterpret ***
 dictionary = objectMemory nilObject ifTrue:
 [MethodDict pointer is nil (hopefully due a swapped out stub)
  -- raise exception #cannotInterpret:.
 self createActualMessageTo: class.
 messageSelector := objectMemory splObj: SelectorCannotInterpret.
  self sendBreak: messageSelector + BaseHeaderSize
 point: (objectMemory lengthOf: messageSelector)
 receiver: nil.
  ^self lookupMethodInClass: (self superclassOf: currentClass)].
 *** trick with the cannotInterpret end ***

  found := self lookupMethodInDictionary: dictionary.
 found ifTrue: [^currentClass].
 ^

 currentClass := self superclassOf: currentClass].

 Could not find #doesNotUnderstand: -- unrecoverable error.
  messageSelector = (objectMemory splObj: SelectorDoesNotUnderstand)
 ifTrue:
 [self error: 'Recursive not understood error encountered'].

 Cound not find a normal message -- raise exception #doesNotUnderstand:
 self createActualMessageTo: class.
  messageSelector := objectMemory splObj: SelectorDoesNotUnderstand.
 self sendBreak: messageSelector + BaseHeaderSize
  point: (objectMemory lengthOf: messageSelector)
 receiver: nil.
 ^self lookupMethodInClass: class


 if (found) {
 return currentClass;
  }


 static sqInt
 lookupMethodInClass(sqInt class)
 {
  // StackInterpreter#lookupMethodInClass:   DECL_MAYBE_SQ_GLOBAL_STRUCT
 sqInt currentClass;
 sqInt dictionary;
 sqInt found;
 sqInt header;
 sqInt index;
 sqInt length;
 sqInt mask;
 sqInt methodArray;
 sqInt nextSelector;
 sqInt sz;
 sqInt wrapAround;

  assert(class != (nilObject()));
 currentClass = class;
  while (currentClass != GIV(nilObj)) {
 dictionary = longAt((currentClass + BaseHeaderSize) +
 (MethodDictionaryIndex  ShiftForWord));
  if (dictionary == GIV(nilObj)) {

 /* ifTrue: */

 createActualMessageTo(class);
 GIV(messageSelector) = longAt((GIV(specialObjectsOop) + BaseHeaderSize) +
 (SelectorCannotInterpret  ShiftForWord));
  sendBreakpointreceiver(GIV(messageSelector) + BaseHeaderSize,
 lengthOf(GIV(messageSelector)), null);
  return lookupMethodInClass(longAt((currentClass + BaseHeaderSize) +
 (SuperclassIndex  ShiftForWord)));
  }
 /* begin lookupMethodInDictionary: */
 /* begin fetchWordLengthOf: */
 /* begin sizeBitsOf: */
 header = longAt(dictionary);
 sz = ((header  TypeMask) == HeaderTypeSizeAndClass

Re: [Pharo-project] SystemNavigation #allSelect:

[Eliot Miranda]

On Sun, Feb 10, 2013 at 8:25 AM, Camillo Bruni camillobr...@gmail.comwrote:

 Why does SystemNavigation  #allSelect: return strings of the form 'Array
 at:' instead of the real methods?


Because its broken.  But it shouldn't return real methods.  It should
return MethodReference instances (or their equivalent, RBMethodDefinition),
as do all the other systemNavigation facilities.
-- 
best,
Eliot

Re: [Pharo-project] SystemNavigation #allSelect:

[Eliot Miranda]

On Sun, Feb 10, 2013 at 8:42 AM, Frank Shearar frank.shea...@gmail.comwrote:

 On 10 February 2013 16:25, Camillo Bruni camillobr...@gmail.com wrote:
  Why does SystemNavigation  #allSelect: return strings of the form
 'Array at:' instead of the real methods?

 Probably because the things that use SystemNavigation - Browsers,
 MessageSets and the like - want to render lists of things to the user.

 There is one advantage to dumb strings, which is that it's easy to
 make a SystemNavigation that works against a remote image. But that's
 not much to go on. Changing these kinds of methods to return
 MethodReferences might be a useful middle ground (and permit easy
 extension to remote tools).


No, dumb strings are dumb.  A className, selector pair (which is what
MethodReference is) is the right thing (and what systemNavigation methods
return).  The dumb strings are a pain in the ass to parse (endlessly
looking for ' class' to spot meta classes etc).  Whereas the class,selector
p[air approach is extensible, e.g. to include a pointer to a specific
external entity (be it Monticello package or remote image).
 MethodReference is what the system has provided for a decade and they're
convenient.  There are multiple versions of these and I could care less
about whether one uses MethodReference or RBMethodDefinition.  But that
they have a consistent API is really important.  Programmatic uses of these
things for code editing is something I've depended upon in the VMMaker, and
I'm anxious that Pharo and Squeak don't diverge hopelssly on this level of
the system.

In my own work I've ended up with three kinds of code reference object

a) MethodReference that points to a class,selector pair
b) ClassReference that points to a class
c) TextReference that holds onto a text

So if one wants to check out a refactoring/edit before applying it one
compares a sequence of MethodReference objects and a matching sequence of
TextReference objects that hold onto the edited source to a comparison
engine.

If one wants to have a look at all uses of a SharedPool one can supply a
list of ClassReference objects to a list browser.

If one wanted to build a compare two images or compare arbitrary package
versions: facility one can extend the reference objects with pointers to
specific packages or remote images.

etc.

Lots of stuff in the system depends on these kinds of pointer; message list
browsers, Monticello's loader, etc.

What's insane is a) not having a standard set of facilities common between
Pharo and Squeak with a well-defined API (e.g. isCodeReference,
isMethodReference, isClassReference), b) having some of the API in
extension methods in e.g. Monticello.

This is core reflection protocol and it needs to be well-defined and in
what ever package contains base reflection protocol.


excuse my ranting.


 I mention remote tools because I hacked up a proof of concept a while
 back that turned a Browser into one that could access a suitably
 prepared image through an HTTP API. Development stalled because the
 reflection machinery's API is a bit... involved, and it was dog slow,
 but I could browse anything I liked. I should really wrap up the work
 a bit so I can spread the love.

 frank




-- 
best,
Eliot

Re: [Pharo-project] New Issue Tracker

[Eliot Miranda]

On Fri, Feb 8, 2013 at 2:22 PM, Marcus Denker marcus.den...@inria.frwrote:


 On Feb 8, 2013, at 10:00 PM, Esteban A. Maringolo emaring...@gmail.com
 wrote:

  (regarding Mantis)
 
  2013/2/8 Stéphane Ducasse stephane.duca...@inria.fr:
  we used it for squeak and I never liked it.
 
  It is ugly as it gets, I don't like its appearance either. I won't
  argue on that :)
 
  But it is reliable, flexible and full of features.
 

 But if you look at it.. they published statistics for Squeak, and
 it was something like 10 people used it in 12 months on 50 bugs
 (or something like that).

 We closed 1500 in not even 10 months… the software used as
 a issue tracker has to be some kind of influence on that.


That's not a valid comparison.  In Squeak trunk bugs are getting fixed at a
much higher rate than that but it isn't tracked on the issue tracker,
because...
we mostly don't use an issue tracker.



 Marcus





-- 
best,
Eliot

Re: [Pharo-project] New Issue Tracker

[Eliot Miranda]

On Fri, Feb 8, 2013 at 2:41 PM, Marcus Denker marcus.den...@inria.frwrote:


 On Feb 8, 2013, at 11:34 PM, Camillo Bruni camillobr...@gmail.com wrote:

 
 
  That's not a valid comparison.  In Squeak trunk bugs are getting fixed
 at a
  much higher rate

 Are you sure? The list that Craig showed at Fosdem was rather short.


I'm pretty  sure [ ;) ], even though I don't have the figures (mainly due
to us not using an issue tracker).  How would Craig provide a full list of
bugs without an issue tracker?



 Marcus





-- 
best,
Eliot

Re: [Pharo-project] New Issue Tracker

[Eliot Miranda]

On Fri, Feb 8, 2013 at 3:10 PM, Marcus Denker marcus.den...@inria.frwrote:


 On Feb 9, 2013, at 12:01 AM, Frank Shearar frank.shea...@gmail.com
 wrote:

  On 8 February 2013 22:51, Marcus Denker marcus.den...@inria.fr wrote:
 
  On Feb 8, 2013, at 11:49 PM, Frank Shearar frank.shea...@gmail.com
 wrote:
 
  On 8 February 2013 22:41, Marcus Denker marcus.den...@inria.fr
 wrote:
 
  On Feb 8, 2013, at 11:34 PM, Camillo Bruni camillobr...@gmail.com
 wrote:
 
 
 
  That's not a valid comparison.  In Squeak trunk bugs are getting
 fixed at a
  much higher rate
 
  Are you sure? The list that Craig showed at Fosdem was rather short.
 
  Well, obviously Squeak is a rather smaller community, so that's hardly
  surprising.
 
  Squeakers _do_ need to use bugs.squeak.org, but as I'm sure you know
  from getting Pharo going, this is partly a matter of education.
 
 
  It is a matter of someone doing it.
 
  ... and convincing people to do it is called education. Note my use of
  the word partly. Anyway, I'm not sure why you're getting stuck into
  this. You sound annoyed.

 I will always be annoyed about that topic… ;-)


Quite right too.  The issue for me is that the bug trackers are not
well-enough integrated into my Squeak work flow.  Montivcello is
beautifully integrated into the work flow and hence a joy to use.  I'm not
proposing reinventing the wheel and writing a Squeak/Pharo bug tracker
(although we did that at ParcPlace/ObjectShare/Cincom and the results were
excellent).  But at the same time I don't want to go to an external web
page to read bugs (althoguh I'm willing to) and I *definitely* don't want
to go there to update fixes.  I want to update fixes from my Monticello
check-in and/or TestRunner.

I wonder whether it is feasible to provide a skin to an existing, popular
bug tracker so that at least one can have the updating/closing side of the
work-flow brought much closer to Monticello check-in/TestRunner?

Wouldn't the ideal work-flow be built around an interface between
TestRunner and a bug tracker?  If we built such an interface wouldn't there
be much greater use?  Imagine being able to have one-click (plus filling in
a description in a submit dialogue) bug creation from TestRunner?  And e.g.
using pragmas or some-such, add the state and history, or simply the
pointer to the bug tracker page, embedded in the test case?  Then one could
read, in-image, the state of the bug long after it was fixed, in the
context of the test that demonstrated the bug and its fix.




 Marcus




-- 
best,
Eliot

Re: [Pharo-project] New Issue Tracker

[Eliot Miranda]

Hi Ben,

please include the squeak list in this discussion  It's clearly
relevant to the whole community.

On Fri, Feb 8, 2013 at 4:12 PM, Benjamin 
benjamin.vanryseghem.ph...@gmail.com wrote:


 On Feb 9, 2013, at 1:06 AM, Eliot Miranda eliot.mira...@gmail.com wrote:



 On Fri, Feb 8, 2013 at 3:10 PM, Marcus Denker marcus.den...@inria.frwrote:


 On Feb 9, 2013, at 12:01 AM, Frank Shearar frank.shea...@gmail.com
 wrote:

  On 8 February 2013 22:51, Marcus Denker marcus.den...@inria.fr wrote:
 
  On Feb 8, 2013, at 11:49 PM, Frank Shearar frank.shea...@gmail.com
 wrote:
 
  On 8 February 2013 22:41, Marcus Denker marcus.den...@inria.fr
 wrote:
 
  On Feb 8, 2013, at 11:34 PM, Camillo Bruni camillobr...@gmail.com
 wrote:
 
 
 
  That's not a valid comparison.  In Squeak trunk bugs are getting
 fixed at a
  much higher rate
 
  Are you sure? The list that Craig showed at Fosdem was rather short.
 
  Well, obviously Squeak is a rather smaller community, so that's hardly
  surprising.
 
  Squeakers _do_ need to use bugs.squeak.org, but as I'm sure you know
  from getting Pharo going, this is partly a matter of education.
 
 
  It is a matter of someone doing it.
 
  ... and convincing people to do it is called education. Note my use of
  the word partly. Anyway, I'm not sure why you're getting stuck into
  this. You sound annoyed.

 I will always be annoyed about that topic… ;-)


 Quite right too.  The issue for me is that the bug trackers are not
 well-enough integrated into my Squeak work flow.  Montivcello is
 beautifully integrated into the work flow and hence a joy to use.  I'm not
 proposing reinventing the wheel and writing a Squeak/Pharo bug tracker
 (although we did that at ParcPlace/ObjectShare/Cincom and the results were
 excellent).  But at the same time I don't want to go to an external web
 page to read bugs (althoguh I'm willing to) and I *definitely* don't want
 to go there to update fixes.  I want to update fixes from my Monticello
 check-in and/or TestRunner.

 I wonder whether it is feasible to provide a skin to an existing, popular
 bug tracker so that at least one can have the updating/closing side of the
 work-flow brought much closer to Monticello check-in/TestRunner?

 Wouldn't the ideal work-flow be built around an interface between
 TestRunner and a bug tracker?  If we built such an interface wouldn't there
 be much greater use?  Imagine being able to have one-click (plus filling in
 a description in a submit dialogue) bug creation from TestRunner?  And e.g.
 using pragmas or some-such, add the state and history, or simply the
 pointer to the bug tracker page, embedded in the test case?  Then one could
 read, in-image, the state of the bug long after it was fixed, in the
 context of the test that demonstrated the bug and its fix.


 That's exactly why Camillo and I spent so much time implementing a Google
 Issue Tracker API in Smalltalk :)
 And why we are looking for an alternative solution providing a scriptable
 API


So two questions.  a) What are the candidates?  b) how much effort do you
think it would be, compared to the interface you've already built,
implementing a bug tracker with a scriptable interface?  It is essentially
an evolveable DB schema plus some triggers to send emails, right?


 Ben





 Marcus




 --
 best,
 Eliot





-- 
best,
Eliot

[Pharo-project] new Cog VMs available

[Eliot Miranda]

http://www.mirandabanda.org/files/Cog/VM/VM.r2678

CogVM binaries as per VMMaker.oscog-eem.264/r2678.

Fix snapshot primitive failure in the StackVM and Cogit.  The
primitive should fail, not merely return the receiver.  Also if in
Cogit, need to back-up instruction pointer on failure.

Make reportMinimumUnusedHeadroom more informative (also print
available headroom).

-- 
best,
Eliot

Re: [Pharo-project] pharo VM names

[Eliot Miranda]

On Tue, Feb 5, 2013 at 7:24 AM, Esteban Lorenzano esteba...@gmail.comwrote:

 Hi,

 1) CI builds names is not the same than app names.
 2) The official pharo vm (the NB Cog JIT), should be named just Pharo,
 because that is what users will see in his dock bar.
 3) The stack VM is not a debug vm is just a VM who uses a
 stack-to-register approach. I would call it PharoS or something that simple.


No.  The StackVM is a VM that optimizes interpreted execution by mapping
contexts to stack frames and lazily instantiating contexts, but is still a
pure interpreter.  The Cog VM is a VM that optimizes execution by mapping
contexts to stack frames and lazily instantiating contexts, /and/ by
compiling methods used more than once to machine-code and implementing a
number of send optimization schemes in that machine-code.


4) RizelVM is not a regularly distributed VM, so it should not be in pharo,
 but in pharo-contribution
 5) PLEASE, STOP MARKING ISSUES THAT CAN WAIT AS 2.0 We are just 2
 weeks of release. Stop adding new tasks. No matter if you think is
 important. Unless it will block us to release, IT IS NOT.

 Thanks,
 Esteban


 On Feb 5, 2013, at 4:08 PM, Camillo Bruni camillobr...@gmail.com wrote:

  We should really decide on this:
 https://code.google.com/p/pharo/issues/detail?id=7423
 
  I guess that would simplify the choice for newcomers significantly!





-- 
best,
Eliot

Re: [Pharo-project] pharo VM names

[Eliot Miranda]

On Tue, Feb 5, 2013 at 1:12 PM, Camillo Bruni camillobr...@gmail.comwrote:

 done:
 https://ci.inria.fr/pharo/view/VM/job/StackVM/
 https://ci.inria.fr/pharo/view/VM/job/PharoVM/


The Pharo VM (former Cog VM) is a VM that optimizes execution by mapping
contexts to stack frames and lazily instantiating contexts.
It further jits/compiles methods used more than once to machine-code and
implements a number of send optimization schemes in that machine-code.
=
The Pharo VM (also known as the Cog VM) is a VM that optimizes execution
by mapping contexts to stack frames and lazily instantiating contexts.
It further jits/compiles methods used more than once to machine-code and
implements a number of send optimization schemes in that machine-code.

please.



 On 2013-02-05, at 22:09, Camillo Bruni camillobr...@gmail.com wrote:

  doing that right now!
 
  On 2013-02-05, at 22:08, Francois Stephany tulipe.mouta...@gmail.com
 wrote:
  On 05/02/13 21:15, Eliot Miranda wrote:
 
 
  No.  The StackVM is a VM that optimizes interpreted execution by
 mapping
  contexts to stack frames and lazily instantiating contexts, but is
 still
  a pure interpreter.  The Cog VM is a VM that optimizes execution
  by mapping contexts to stack frames and lazily instantiating contexts,
  /and/ by compiling methods used more than once to machine-code and
  implementing a number of send optimization schemes in that
 machine-code.
 
 
  This could be added in the Jenkins job description!
 
 





-- 
best,
Eliot

Re: [Pharo-project] pharo VM names

[Eliot Miranda]

On Tue, Feb 5, 2013 at 1:21 PM, Camillo Bruni camillobr...@gmail.comwrote:


 On 2013-02-05, at 22:15, Eliot Miranda eliot.mira...@gmail.com wrote:

  On Tue, Feb 5, 2013 at 1:12 PM, Camillo Bruni camillobr...@gmail.com
 wrote:
 
  done:
  https://ci.inria.fr/pharo/view/VM/job/StackVM/
  https://ci.inria.fr/pharo/view/VM/job/PharoVM/
 
 
  The Pharo VM (former Cog VM) is a VM that optimizes execution by mapping
  contexts to stack frames and lazily instantiating contexts.
  It further jits/compiles methods used more than once to machine-code and
  implements a number of send optimization schemes in that machine-code.
  =
  The Pharo VM (also known as the Cog VM) is a VM that optimizes execution
  by mapping contexts to stack frames and lazily instantiating contexts.
  It further jits/compiles methods used more than once to machine-code and
  implements a number of send optimization schemes in that machine-code.

 nope it is NOT the cog VM, your branch doesn't have a set of changes we
 made,
 notably to the file plugins, furthermore we ship by default with the native
 boost plugin.

 so to be fully correct I have to say *former*.


No.  Cog is an architecture, a JIT plus an Interpreter, not a specific VM.
 StackVM is an architecture.  Interpreter VM is an architecture. You could
clarify by saying

The Pharo VM (a derivative of the Cog VM) ...

or The Pharo VM (a version of the Cog VM) ...

-- 
best,
Eliot

Re: [Pharo-project] pharo VM names

[Eliot Miranda]

On Tue, Feb 5, 2013 at 2:24 PM, Igor Stasenko siguc...@gmail.com wrote:

 On 5 February 2013 22:27, Eliot Miranda eliot.mira...@gmail.com wrote:
 
 
  On Tue, Feb 5, 2013 at 1:21 PM, Camillo Bruni camillobr...@gmail.com
  wrote:
 
 
  On 2013-02-05, at 22:15, Eliot Miranda eliot.mira...@gmail.com wrote:
 
   On Tue, Feb 5, 2013 at 1:12 PM, Camillo Bruni
   camillobr...@gmail.comwrote:
  
   done:
   https://ci.inria.fr/pharo/view/VM/job/StackVM/
   https://ci.inria.fr/pharo/view/VM/job/PharoVM/
  
  
   The Pharo VM (former Cog VM) is a VM that optimizes execution by
   mapping
   contexts to stack frames and lazily instantiating contexts.
   It further jits/compiles methods used more than once to machine-code
 and
   implements a number of send optimization schemes in that
 machine-code.
   =
   The Pharo VM (also known as the Cog VM) is a VM that optimizes
   execution
   by mapping contexts to stack frames and lazily instantiating contexts.
   It further jits/compiles methods used more than once to machine-code
 and
   implements a number of send optimization schemes in that
 machine-code.
 
  nope it is NOT the cog VM, your branch doesn't have a set of changes we
  made,
  notably to the file plugins, furthermore we ship by default with the
  native
  boost plugin.
 
  so to be fully correct I have to say *former*.
 
 
  No.  Cog is an architecture, a JIT plus an Interpreter, not a specific
 VM.
  StackVM is an architecture.  Interpreter VM is an architecture. You could
  clarify by saying
 
  The Pharo VM (a derivative of the Cog VM) ...
 
  or The Pharo VM (a version of the Cog VM) ...
 

 i agree, formely is not good choice of word, granted that we are
 regularly merging with your
 code base and exchange improvements  fixes.


thank you Igor.  I agree.  PharoVM is a version of Cog.  I'm not claiming
that Cog is the PharoVM, but the PharoVM is substantially, and
architecturally, a Cog VM.




  --
  best,
  Eliot



 --
 Best regards,
 Igor Stasenko.




-- 
best,
Eliot

Re: [Pharo-project] [vwnc] Does anyone have a new string literal?

[Eliot Miranda]

On Fri, Feb 1, 2013 at 9:47 AM, Terry Raymond traym...@craftedsmalltalk.com
 wrote:

 I constantly run into the situation where I am incorporating either HTML
 or javascript

 in my methods. The problem I run into is the smalltalk string quote(‘). It
 is a real pain

 to double quote it, and don’t even try to copy and paste external
 javascript.

 ** **

 So, I think it would be real helpful to have some other funky string quote
 like

 ##{{ }}## or some sequence that is very unlikely to occur in another
 language.

 ** **

 Has anyone done this or even thought about it?


David Leibs has been pushing a well-thought-through facility he calls (and
other systems name) quasi-quote.  Here, a string literal contains escape
sequences, a little like printf, that allow one to substitute values.
 Dave's syntax uses square brackets to escape into Smalltalk.  So that
(IIRC) you say things like

'htmlhead/headbodyH1[myHeading]/H1'

which compiles to something analogous to

String streamContents: [:s| s
nextPutAll: 'htmlhead/headbodyH1'; nextPutAll: myHeading
asString; nextPutAll: '/H1]

But this excellent suggestion has fallen on deaf ears (my own included) for
more than a decade.



 ** **

 Terry

 ** **

 ===

 Terry Raymond

 Crafted Smalltalk

 80 Lazywood Ln.

 Tiverton, RI  02878

 (401) 624-4517  traym...@craftedsmalltalk.com 

 ===

 ** **

 ___
 vwnc mailing list
 v...@cs.uiuc.edu
 http://lists.cs.uiuc.edu/mailman/listinfo/vwnc




-- 
best,
Eliot

Re: [Pharo-project] [vwnc] Does anyone have a new string literal?

[Eliot Miranda]

On Fri, Feb 1, 2013 at 10:28 AM, Eliot Miranda eliot.mira...@gmail.comwrote:



 On Fri, Feb 1, 2013 at 9:47 AM, Terry Raymond 
 traym...@craftedsmalltalk.com wrote:

 I constantly run into the situation where I am incorporating either HTML
 or javascript

 in my methods. The problem I run into is the smalltalk string quote(‘).
 It is a real pain

 to double quote it, and don’t even try to copy and paste external
 javascript.

 ** **

 So, I think it would be real helpful to have some other funky string
 quote like

 ##{{ }}## or some sequence that is very unlikely to occur in another
 language.

 ** **

 Has anyone done this or even thought about it?


 David Leibs has been pushing a well-thought-through facility he calls (and
 other systems name) quasi-quote.  Here, a string literal contains escape
 sequences, a little like printf, that allow one to substitute values.
  Dave's syntax uses square brackets to escape into Smalltalk.  So that
 (IIRC) you say things like

 'htmlhead/headbodyH1[myHeading]/H1'

 which compiles to something analogous to

 String streamContents: [:s| s
 nextPutAll: 'htmlhead/headbodyH1'; nextPutAll: myHeading
 asString; nextPutAll: '/H1]

 But this excellent suggestion has fallen on deaf ears (my own included)
 for more than a decade.


blush, saw quote, brian farted, now realize this is nothing to do with
your issue Terry.  Apologies/blush.

But you could come up with some convention to embed in quasi-quote to
change the string quote, right?  he thing is to choose your escape
character(s) with care.  You need a quote to escape to and from processing
($[  $]).  You need a literal quote ( $\ ?).  Do you need a third quote to
change quote interpretation?  Or do you need a third quote that turns off
single quote as end of string?  eg. say $^ indicates no close quote until
the matching $^.  So the following
'^'my single-quoted string'^'
denotes
'''my single-quoted string'''

and I realize I can't remember how David's proposal distinguishes between
quasi-quote strings and normal Smalltalk strings.


 

 ** **

 Terry

 ** **

 ===

 Terry Raymond

 Crafted Smalltalk

 80 Lazywood Ln.

 Tiverton, RI  02878

 (401) 624-4517  traym...@craftedsmalltalk.com 

 ===

 ** **

 ___
 vwnc mailing list
 v...@cs.uiuc.edu
 http://lists.cs.uiuc.edu/mailman/listinfo/vwnc




 --
 best,
 Eliot




-- 
best,
Eliot

Re: [Pharo-project] [squeak-dev] Re: [vwnc] Does anyone have a new string literal?

[Eliot Miranda]

On Fri, Feb 1, 2013 at 10:44 AM, Colin Putney co...@wiresong.com wrote:




 On Fri, Feb 1, 2013 at 10:28 AM, Eliot Miranda eliot.mira...@gmail.comwrote:


 David Leibs has been pushing a well-thought-through facility he calls
 (and other systems name) quasi-quote.  Here, a string literal contains
 escape sequences, a little like printf, that allow one to substitute
 values.  Dave's syntax uses square brackets to escape into Smalltalk.


 That's certainly a useful construct, but I don't think it addresses
 Terry's problem. He wants a string literal that can include $' and CR
 without escaping. Something like HEREDOC or Python's triple-double-quote
 string literals.


If I had a brain I would have remembered the syntax and hence that it does
address Terry's point.  The quote character for quasi-quote is ` (back
tick), so single ticks are literal inside a quasi-quote.
 blushSorry/blush


 Colin






-- 
best,
Eliot

[Pharo-project] new Cog VMs available

[Eliot Miranda]

...at http://www.mirandabanda.org/files/Cog/VM/VM.r2677/.

CogVM binaries as per VMMaker.oscog-eem.261/r2677.

Move determination of the ammount of headroom to the platform in
osCogStackPageHeadroom (in the various sqFooMain.c files). Hence
2k stack pages on Mac and Win32 with 4k pages on linux.

Provide a routine to monitor the ammount of unused headroom, which
requires the stack memory be zeroed before use.  Assume the platform
will provide a -reportheadroom flag for enabling the report.  Provide
primitiveMinimumUnusedHeadroom for in-image access.
-- 
best,
Eliot

Re: [Pharo-project] NativeBoost linux 8 byte structures

[Eliot Miranda]

On Sun, Jan 27, 2013 at 2:26 PM, Ciprian Teodorov 
ciprian.teodo...@gmail.com wrote:

 Hi Guys,

 Today I wanted to test my TalkFFI project on linux, and I run into some NB
 issue.
 It seems that the VM crashes when trying to invoke a function returning a
 8 byte structure.
 I have tried with 4 bytes structure and I get some bogus data but no crash
 with 12 bytes structure it seems to work...


I suspect this is a win32/linux difference that NB doesn't handle yet.  On
win32 power-of-two structures = 8 bytes in length are returned in
registers.  On linux they're always returned through memory.  Here are the
relevant defs from the ThreadedIA32FFIPlugin


#if defined(_X86_) || defined(i386) || defined(__i386) || defined(__i386__)
/* Both Mac OS X x86 and Win32 x86 return structs of a power of two in size
 * less than or equal to eight bytes in length in registers. Linux never
does so.
 */
# if __linux__
# define WIN32_X86_STRUCT_RETURN 0
# else
# define WIN32_X86_STRUCT_RETURN 1
# endif

#define returnStructInRegisters(sz) (WIN32_X86_STRUCT_RETURN  (sz) = 8
 !((sz)((sz)-1)))


HTH

Attached to this mail you will find a simple test case.

 the c file I have compiled with:

 gcc -g -fPIC -Wall -c -m32 strreturn.c
 gcc -shared -g -Wl,-soname,libret.so.1 -o libret.so -m32 strreturn.o -lc

 Cheers,
 --
 Dr. Ciprian TEODOROV
 Ingénieur Développement CAO

 tél : 06 08 54 73 48
 mail : ciprian.teodo...@gmail.com
 www.teodorov.ro




-- 
best,
Eliot

Re: [Pharo-project] [squeak-dev] AndreasSystemProfiler Released MIT

[Eliot Miranda]

On Wed, Jan 23, 2013 at 12:58 PM, Ron Teitelbaum r...@usmedrec.com wrote:

 Hello All,

 In Memory of Andreas Raab
 http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html

 We have renamed and released the AndreasSystemProfiler.


Both AndreasSystemProfiler and MessageTally are periodic sampling
profilers.  The essential difference between AndreasSystemProfiler and
MessageTally is in how the current method is sampled.

MessageTally is driven from a high-priority process in a loop waiting on a
delay.  When the delay fires the lower-priority process being profiled is
interrupted, its stack is walked to determine the methods along the call
chain, and that data is recorded.  But since the sampling occurs when the
high-priority process preempts the lower-priority process, a sample is only
taken at a preemption point.  In particular, primitives are *not* profiled
because they are not suspension points.  A process can only be suspended on
method activation (a non-primitive method activation, or primitive failure)
or on backward branch.  The cost of primitives is charged to a caller and
is inferred by subtracting the cost of children of the caller from the
caller itself (subtracting the number of samples in children of the caller
form the number of samples in the caller itself).

Another problem is that using the clock that underlies Delay, which is
typically the clock used by processes being profiled, causes sampling
errors due to the sampling and sampled processes cohering.  Delays are
limited in resolution (at best 1 millisecond) so if the profiled process
waits on a delay it'll fire immediately after the profiling process
(because the profiling process is at higher priority) and so the sampling
process may only ever see the sampled process in a wait state.

If MessageTally is used to profile multiple processes then a third problem
is that if a primitive causes a process switch then its cost will end up
being charged to the process switched-to, not switched from.  This is again
because sampling can only occur after a primitive has completed
(successfully or not).

AndreasSystemProfiler is driven from a high-priority process in a loop
waiting on a Semaphore known to the VM.  The profiling process uses a
primitive to schedule a sample some number of ticks of the VM's
high-performance clock in the future.  When the time is reached the VM
samples the current method and the current process, *before any process
preemption takes place*, and independently of the standard clock, and
signals the semaphore.  The profiling process then collects the
method,process pair via primitives.  So AndreasSystemProfiler provides much
more accurate results.

That said there are still limitations with primitives and Cog.  Currently
Cog only samples interpreter primitives.  Those primitives it implements
in machine code (integer and float arithmetic, closure evaluation, at:,
identityHash) are not sampled and won't show up; they will be charged to
the calling method.  This is fixable, since Cog actually compiles the
sampling direct into interpreter primitive invocation when profiling is in
effect and not at other times, but sampling could be a significant cost in
these simple and performance-critical primitives.

http://ss3.gemstone.com/ss/AndreasSystemProfiler.html

 Using the MIT License.

 Thank you Eliot for your help to get this ready.  The profiler works with
 Squeak 4.4.

 All the best,

 Ron Teitelbaum, Julie LeMoine and David Smith

  -Original Message-
  From: squeak-dev-boun...@lists.squeakfoundation.org [mailto:squeak-dev-
  boun...@lists.squeakfoundation.org] On Behalf Of Andreas.Raab
  Sent: Friday, January 11, 2013 1:39 PM
  To: squeak-...@lists.squeakfoundation.org
  Subject: [squeak-dev] Re: Profiling
 
  Levente Uzonyi-2 wrote
   It uses some primitives which were added to the CogVM, so it requires
 Cog.
   We could reimplement it from scratch using the same primitives and get
   a better profiler in the image. We can't include this due to the GPL
   license.
 
  Or ask Ron if 3dicc (which bought all the rights to the Teleplace IP and
  Software) can re-release the code under a more permissable license.
 
  Cheers,
- Andreas
 
 
 
 
  --
  View this message in context: http://forum.world.st/Profiling-
  tp4662704p4662987.html
  Sent from the Squeak - Dev mailing list archive at Nabble.com.
 






-- 
best,
Eliot

Re: [Pharo-project] about the VM and Pharo

[Eliot Miranda]

On Wed, Jan 23, 2013 at 9:01 AM, Igor Stasenko siguc...@gmail.com wrote:

 On 23 January 2013 17:27, Sean P. DeNigris s...@clipperadams.com wrote:
  EstebanLM wrote
  Pharo 2.0 will be released with a stable, branded vm with a bunch of
  useful plugins and libraries (like freetype) and out-of-the-box support
  for NativeBoost.
  ...
  For Pharo 3.0 we are even more ambitious: we want to start replacing
 some
  important parts of the vm with plugins (like extract a DisplayPlugin,
 so
  we can control from image side the initialization of a morphic world or
  something extra. And we want to replace BitBlt plugin with Athens, so
 that
  will keep us busy enough time.
 
  Wow, very exciting! Thank everyone for the hard work :)
 
 
  EstebanLM wrote
  - ephemerons support.
 
  Is this currently available? If so, does that mean that weak
 announcements
  taking a block are now working properly?
 
 no it is not integrated yet.
 After discussing with Eliot, he recommended to use last object format
 to denote ephemerons.
 Existing implementation is a bit hackish way to determine if object is
 ephemeron.
 So, before we do such change, assume they are not working yet.


Yes, please.  This is the only thing that has kept me from integrating the
ephemeron work.  We can use instSpec/format #5.  The instSpec/formats are
0: zero-fixed-sized pointers (e.g. UndefinedObject)
1: non-zero-fixed-sized pointers (e.g. Point (x,y))
2: zero-fixed-size variable pointers (e.g. Array)
3. non-zero-fixed-sized variable pointers (e.g. AdditionalMethodState
(method,selector))
4. arbitrary-fixed-sized variable weak pointers (e.g. WeakFinalizerItem
(list,next,executor)
5. unused
6. variable 32-bit non-pointers (e.g. Float)
7. unused (but should be odd bit for length of format 6 objects in 64-bit
system)
8. variable 8-bit non-pointers (e.g. ByteArray, String)
9,10,11 odd bits for length of format 8 objects
12 hybrid variable pointers, variable bytes (CompiledMethod and subclasses)
13,14,15 odd bits for length of format 12 objects

So 5 is the obvious one. format = 5 are pointers, format = 5 or = 12
contain pointers.  7's a really bad choice.

And I won't bore you with the extension to 64-bits and a 5 bit field.


  Also, is the Pharo branded VM on the static file server based on Jit Cog
 (as
  opposed to stack, etc)?
 
 which server?

  Cheers,
  Sean
  --
  View this message in context:
 http://forum.world.st/about-the-VM-and-Pharo-tp4664887p4664902.html
  Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
 



 --
 Best regards,
 Igor Stasenko.




-- 
best,
Eliot

Re: [Pharo-project] Class initialisation after loading

[Eliot Miranda]

On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar frank.shea...@gmail.comwrote:

 On 17 January 2013 17:45, Eliot Miranda eliot.mira...@gmail.com wrote:
 
 
 
  On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko siguc...@gmail.com
 wrote:
 
  After some thought i decided to contribute my 2cents.
 
  First, i think it is impossible to introduce a (re)initialization
  logic which would suit all different scenarios.
  Because it is really depends on what is stored in class variables and/or
  pools
  and if you add subclasses and then instances into the soup, you might
  end up with something
  which is really hard to safely reinitialize, because it may have some
  inconsistent state at different stages
  of initialization. It also, sometimes an order of initialization is
  important.
 
 
  Yes, but on *can* write idempotent class initialization code.  So that if
  the system does reinitialize on every load old code may break until its
  fixed, but new code will have the advantage of always being correctly
  initialized.  Note that in the VMMaker class reinitializations of the
 core
  VM classes (the interpreter, garbage collector, jit, etc) are done *on
 each
  launch of the simulator*, and *each vm generation*, let alone on each
  package load :).  [ I'm not recommending this :) ].
 
  One thing I do is when creating singletons for sentinels etc I check
 whether
  they've been initialized. e.g.
 
  initialize
  Sentinel ifNil: [Sentinel := Object new]

 Knowing full well that I know next to nothing about concurrency in the
 image, and so realising that this might be a complete non-issue: lazy
 initialization and concurrency do not mix well.


Agreed, but the two can be decoupled.  For example one can build the state
and then assign it.  Assignment is currently atomic so there are no
multicore issues here (yet :) ).  And (I'm sure you realize, for give the
pedantry) the above example isn't lazy, it is eager.  It simply refuses to
create another Sentinel if one exists already.


 But I do agree with your sentiment: idempotency is highly desirable,
 and somehow forcing non-idempotent class initialisation to fail
 quickly and noisily sounds like a good plan.

 frank

-- 
best,
Eliot

Re: [Pharo-project] Class initialisation after loading

[Eliot Miranda]

phhh, let me try again :)


On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar frank.shea...@gmail.comwrote:

 On 17 January 2013 17:45, Eliot Miranda eliot.mira...@gmail.com wrote:
 
 
 
  On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko siguc...@gmail.com
 wrote:
 
  After some thought i decided to contribute my 2cents.
 
  First, i think it is impossible to introduce a (re)initialization
  logic which would suit all different scenarios.
  Because it is really depends on what is stored in class variables and/or
  pools
  and if you add subclasses and then instances into the soup, you might
  end up with something
  which is really hard to safely reinitialize, because it may have some
  inconsistent state at different stages
  of initialization. It also, sometimes an order of initialization is
  important.
 
 
  Yes, but on *can* write idempotent class initialization code.  So that if
  the system does reinitialize on every load old code may break until its
  fixed, but new code will have the advantage of always being correctly
  initialized.  Note that in the VMMaker class reinitializations of the
 core
  VM classes (the interpreter, garbage collector, jit, etc) are done *on
 each
  launch of the simulator*, and *each vm generation*, let alone on each
  package load :).  [ I'm not recommending this :) ].
 
  One thing I do is when creating singletons for sentinels etc I check
 whether
  they've been initialized. e.g.
 
  initialize
  Sentinel ifNil: [Sentinel := Object new]

 Knowing full well that I know next to nothing about concurrency in the
 image, and so realising that this might be a complete non-issue: lazy
 initialization and concurrency do not mix well.


Agreed, but the two can be decoupled.  For example one can build the state
and then assign it.  Assignment is currently atomic so there are no
multicore issues here (yet :) ).  Further, assignments are not suspension
points so a sequence of (just) assignments are guaranteed to occur without
interruption.  And (I'm sure you realize, for give the pedantry) the above
example isn't lazy, it is eager.  It simply refuses to create another
Sentinel if one exists already.


 But I do agree with your sentiment: idempotency is highly desirable,
 and somehow forcing non-idempotent class initialisation to fail
 quickly and noisily sounds like a good plan.

 frank

-- 
best,
Eliot

Re: [Pharo-project] Class initialisation after loading

[Eliot Miranda]

On Fri, Jan 18, 2013 at 2:38 PM, Frank Shearar frank.shea...@gmail.comwrote:

 On 18 January 2013 21:49, Eliot Miranda eliot.mira...@gmail.com wrote:
  phhh, let me try again :)
 
 
  On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar frank.shea...@gmail.com
  wrote:
 
  On 17 January 2013 17:45, Eliot Miranda eliot.mira...@gmail.com
 wrote:
  
  
  
   On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko siguc...@gmail.com
   wrote:
  
   After some thought i decided to contribute my 2cents.
  
   First, i think it is impossible to introduce a (re)initialization
   logic which would suit all different scenarios.
   Because it is really depends on what is stored in class variables
   and/or
   pools
   and if you add subclasses and then instances into the soup, you might
   end up with something
   which is really hard to safely reinitialize, because it may have some
   inconsistent state at different stages
   of initialization. It also, sometimes an order of initialization is
   important.
  
  
   Yes, but on *can* write idempotent class initialization code.  So that
   if
   the system does reinitialize on every load old code may break until
 its
   fixed, but new code will have the advantage of always being correctly
   initialized.  Note that in the VMMaker class reinitializations of the
   core
   VM classes (the interpreter, garbage collector, jit, etc) are done *on
   each
   launch of the simulator*, and *each vm generation*, let alone on each
   package load :).  [ I'm not recommending this :) ].
  
   One thing I do is when creating singletons for sentinels etc I check
   whether
   they've been initialized. e.g.
  
   initialize
   Sentinel ifNil: [Sentinel := Object new]
 
  Knowing full well that I know next to nothing about concurrency in the
  image, and so realising that this might be a complete non-issue: lazy
  initialization and concurrency do not mix well.
 
 
  Agreed, but the two can be decoupled.  For example one can build the
 state
  and then assign it.  Assignment is currently atomic so there are no
  multicore issues here (yet :) ).  Further, assignments are not suspension
  points so a sequence of (just) assignments are guaranteed to occur
 without
  interruption.  And (I'm sure you realize, for give the pedantry) the
 above
  example isn't lazy, it is eager.  It simply refuses to create another
  Sentinel if one exists already.

 So because of the assignment guarantees we won't have two processes
 entering the ifNil: block? (I'll try extract one foot from my mouth
 and maybe replace it with another...)

 In this particular case things seem pretty innocuous: let's say two
 processes enter the #initialize. They both manage to enter the ifNil:
 (I'm aware this is compiled away to jumps, but the impact of this I
 don't know) through a time-of-check-time-of-use race, and you end up
 generating two objects. But one's simply lost. As long as references
 to Sentinel don't escape the class, no one need know anything at all.


right. but good point.  i hadn't thought of this case.  the scenarios i'm
thinking of are those where one is loading/updating a monticello or fuel
package or similar or redefining a class initialize method.  in these
scenarios there's only likely to be one thread of control running the
initialize.



 frank

  But I do agree with your sentiment: idempotency is highly desirable,
  and somehow forcing non-idempotent class initialisation to fail
  quickly and noisily sounds like a good plan.
 
  frank
 
  --
  best,
  Eliot




-- 
best,
Eliot

Re: [Pharo-project] Class initialisation after loading

[Eliot Miranda]

On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko siguc...@gmail.com wrote:

 After some thought i decided to contribute my 2cents.

 First, i think it is impossible to introduce a (re)initialization
 logic which would suit all different scenarios.
 Because it is really depends on what is stored in class variables and/or
 pools
 and if you add subclasses and then instances into the soup, you might
 end up with something
 which is really hard to safely reinitialize, because it may have some
 inconsistent state at different stages
 of initialization. It also, sometimes an order of initialization is
 important.


Yes, but on *can* write idempotent class initialization code.  So that if
the system does reinitialize on every load old code may break until its
fixed, but new code will have the advantage of always being correctly
initialized.  Note that in the VMMaker class reinitializations of the core
VM classes (the interpreter, garbage collector, jit, etc) are done *on each
launch of the simulator*, and *each vm generation*, let alone on each
package load :).  [ I'm not recommending this :) ].

One thing I do is when creating singletons for sentinels etc I check
whether they've been initialized. e.g.

initialize
Sentinel ifNil: [Sentinel := Object new]

This avoids breaking existing instances that would end up referring to an
older value for Sentinel.  Much the same goes for any class state that
would end up in an instance.  One can use become: here too.

What we missing, i think is a package pre/post load/update action(s)
 which tied directly to the package,
 so developer can decide by himself what needs to be (re)initialized
 and in what order without need of having some automated tool to decide
 it (often wrongly).


The question is which is better, hooks to allow control of initialization
on package load (be it Monticello or Fuel) or simple rules for (frequent)
reinialization?  The former allows one to write naive initialization but at
the cost of mastering some complex mechanisms in package loading.  The
latter forces one to write careful initialization code but has the benefit
of simple package loading rules.  Further, writing idempotent class
initialization code is only a problem with complex class initialization
code, and presumably a programmer who is writing such complex code is up to
the task of making it idempotent.  In simple cases, writing idempotent code
should be simple.

Personally I'm starting to prefer the latter approach because the
complexity ends up in common Smalltalk code (class initialization) and in
one place instead of in special Smalltalk code (package loading hooks) in
multiple places (all the various package systems).  The tools always
support common Smalltalk code better than these special hooks.  For
example, load scripts may be stored as strings in packages, and there-in
senders and implementors won't find them.

There are, I think, great advantages to having a system composed of freely
reinitializable components.  It is one of Gilad Bracha's design goals
behind Newspeak to allow running programs to be updated on the fly as fixes
are released.  Gilad particularly likes the fact that this means one can
discard legacy code, since all (if this vision is realized) Newspeak
programs should be at the latest version.  A Smalltalk system with this
property would be far more reliable.  Imagine a long-running server
application that is simply updated as and when bug fixes are available.

I think that forcing frequent class reinitialization and forcing users to
write idempotent class initialization is consistent with Pharo's
philosophical position on fixing broken things, and on good documentation
and simplicity.  I also think that it's a good idea.

I would really like that one day we could have packages as a
 first-class entities in a system, so we could express things in simple
 way:

 Package named: #Foo.

 Foo onLoad
   perform an action when the package is first loaded into image
MyClass initialize.

 Foo onUpdate: oldVersion
   perform an action when different version of package is loaded into
 image
MyClass reinitialize.

 of course, being able to control those actions is just a tip of the
 iceberg.


Yes, this is exactly the route I took with VisualWorks parcels.  And it was
necessary because the code we packaged was legacy and we didn't have the
cycles to rewrite that code.  But I think it's too complex.  It adds
another layer to class loading, with its own conventions, that may be
specific to a particular package system.  Whereas if the rule is your
class will be reinitialized whenever it is loaded in whatever form it's
simple, unambiguous and something one can cope with.

KISS.


 P.S. i know that MC supports package pre/post load scripts (but
 strangely i cannot find where).
 so, it is really opaque to all of the tools, since it is outside of
 the source codebase of the package.

 P.P.S. Metacello also supports pre/post actions, so i think right now
 a best place 

Re: [Pharo-project] [Vm-dev] Fwd: How can the main window title in Squeak and Pharo be set?

[Eliot Miranda]

On Sat, Jan 12, 2013 at 12:39 AM, stephane ducasse 
stephane.duca...@gmail.com wrote:


 
 
  and an additional piece of history is that a number of plugins,
 including the HostWindowPlugin, were enhanced at Qwaq/Teleplace (now 3d
 ICC), in a cross-platform manner since we supported Mac and Windows
 initially and later had a linux prototype.  The code for some of these
 enhanced plugins, including the HostWindowPlugin, was released along with
 Cog, which has an MIT license.  So if you mine the COg branch you'll find
 code that can be folded back into trunk you'll get the enhanced
 functionality.  For the Qwaq/Teleplace HostWindowPlugin that included
 setting the window title, repositioning and resizing the main window,
 querying its size, etc.

 Eliot
 I thought that the code from teleplace was under GPL.


All the image code from Teleplace is GPL.  I'm hoping that specific code
such as Andreas' improved profiler will be released under the MIT license.
 Fingers crossed :)


 The code for Cog made by teleplace is under another license (MIT)?


The VM is of course MIT otherwise the community wouldn't be using it :)

Stef

-- 
best,
Eliot

Re: [Pharo-project] Fwd: How can the main window title in Squeak and Pharo be set?

[Eliot Miranda]

On Fri, Jan 11, 2013 at 5:34 AM, Torsten Bergmann asta...@gmx.de wrote:

 From the history of Squeak and Pharo you can:

   1. Squeak.exe (VM for Windows) was always able to set this using
  the Setting WindowTitle in Pharo.ini - see
  http://squeakvm.org/win32/settings.html

  This was implemented by Andreas Raab (maintainer of SqueakVM)

   2. Later there was the idea in Squeak for a project
  called Areithfa Ffenestri that should add more
  support code to Squeak to allow access to the
  native window or open new ones:

http://wiki.squeak.org/squeak/3862

  This is a VM plugin that is not in all VM's and even after
  years AFAIK not fully implemented on all platforms.

  If it is available then you can do what Bert Freudenberg
  suggested here:


 http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-January/167766.html

  Dont know if the Pharo VM maintainers added this plugin
  too. You have to ask Igor or Esteban.

   3. While Squeak tries to stay platform independent and
  encapsulate platform dependent logic mostly into VM plugins
  to unify the access  there is some other idea in Pharo now:

  With the growing need to easily access platform logic
  of the underlying OS or access external libraries written in
  other languages there is a new FFI plugin which is
  (since Pharo 2.0) will be included in the standard distribution.

  This new Foreign Function Interface (FFI) is called
  NativeBoost and will move more logic into Smalltalk
  itself. So you dont have to write/compile a plugin.

  You just need a VM with NativeBoost support (NBCog.exe on Windows)

  Using native Boost (when in Pharo 2.0) you can (already!)
  write:

NBWin32Window getFocus setWindowText: 'Hello using Native Boost'

  to change the window title. Internally I just call the
  Windows Win32-API function SetWindowTextA using the
  window handle.

  If someone from other platforms implements an NBUnixWindow,
  NBMacWindow, NBRiscOSWindow, ... we can also implement a
  common interface class (NBPharoWindow for example).


and an additional piece of history is that a number of plugins, including
the HostWindowPlugin, were enhanced at Qwaq/Teleplace (now 3d ICC), in a
cross-platform manner since we supported Mac and Windows initially and
later had a linux prototype.  The code for some of these enhanced plugins,
including the HostWindowPlugin, was released along with Cog, which has an
MIT license.  So if you mine the COg branch you'll find code that can be
folded back into trunk you'll get the enhanced functionality.  For the
Qwaq/Teleplace HostWindowPlugin that included setting the window title,
repositioning and resizing the main window, querying its size, etc.


 Hope this helps a little bit


+1.
-- 
best,
Eliot

Re: [Pharo-project] [squeak-dev] Global variable lookup

[Eliot Miranda]

On Fri, Jan 11, 2013 at 11:05 AM, Igor Stasenko siguc...@gmail.com wrote:

 FYI, this is a code from Pharo, which we are did _right_ (of course
 from Pharo perspective ;)


+1.  local variable definitions override explicitly imported variable
definitions inherited variable definitions override global variable
definitions.

But does the system automatically recompile importers of shared pools when
bindings are added or removed from shared pools?  At least Squeak does not.
 And this is an issue in the context of loading Monticello packages.  With
the VMMaker I refactored a lot of globals into shared p[ools when I
decomposed ObjectMemory from the Interpreter hierarchy and added the Cogit
hierarchy.  I would have to manually recompile to get the references right
on e.g. moving a variable from being a class variable of ObjectMemory into
some shared pool, or on moving the variable from one shared pool to another.



 ClassbindingOf: varName
 Answer the binding of some variable resolved in the scope of the
 receiver, or nil
 if variable with such name is not defined

 The lookup recurses up to superclasses looking inside their class
 and shared pools,
 but not the environment, since two classes, even if they have
 ancestry relationship,
 could use different environments.
 That's why we doing an environment lookup only as a last step of
 symbol lookup
 and taking only the environment of receiver only, not any of it's
 superclass(es) 

 | aSymbol binding |
 aSymbol := varName asSymbol.

 ^ (self innerBindingOf: aSymbol) ifNil: [
  self environment bindingOf: aSymbol
 ]


 ClassinnerBindingOf: aSymbol
 Answer the binding of some variable resolved in the scope of the
 receiver, or one of its superclass
 but do not look up binding in receiver's environment.
 Use #bindingOf: for looking up the variable binding in a full
 scope,
 including receiver's environment

 | binding |

 First look in classVar dictionary.
 binding := self classPool bindingOf: aSymbol.
 binding ifNotNil: [^binding].

 Next look in shared pools.
 self sharedPools do: [:pool |
 | aBinding |
 aBinding := pool bindingOf: aSymbol.
 aBinding ifNotNil: [^aBinding ].
 ].

 superclass ifNotNil: [
 ^ superclass innerBindingOf: aSymbol.
 ].
 ^ nil


 On 11 January 2013 19:28, Bert Freudenberg b...@freudenbergs.de wrote:
  bindingOf:environment:



 --
 Best regards,
 Igor Stasenko.




-- 
best,
Eliot

Re: [Pharo-project] Fwd: How can the main window title in Squeak and Pharo be set?

[Eliot Miranda]

On Fri, Jan 11, 2013 at 10:57 AM, Frank Church vfcli...@gmail.com wrote:

 On 11 January 2013 13:34, Torsten Bergmann asta...@gmx.de wrote:
  From the history of Squeak and Pharo you can:
 
1. Squeak.exe (VM for Windows) was always able to set this using
   the Setting WindowTitle in Pharo.ini - see
   http://squeakvm.org/win32/settings.html
 
   This was implemented by Andreas Raab (maintainer of SqueakVM)
 
2. Later there was the idea in Squeak for a project
   called Areithfa Ffenestri that should add more
   support code to Squeak to allow access to the
   native window or open new ones:
 
 http://wiki.squeak.org/squeak/3862
 
   This is a VM plugin that is not in all VM's and even after
   years AFAIK not fully implemented on all platforms.
 
   If it is available then you can do what Bert Freudenberg
   suggested here:
 
 
 http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-January/167766.html
 
   Dont know if the Pharo VM maintainers added this plugin
   too. You have to ask Igor or Esteban.
 
3. While Squeak tries to stay platform independent and
   encapsulate platform dependent logic mostly into VM plugins
   to unify the access  there is some other idea in Pharo now:
 
   With the growing need to easily access platform logic
   of the underlying OS or access external libraries written in
   other languages there is a new FFI plugin which is
   (since Pharo 2.0) will be included in the standard distribution.
 
   This new Foreign Function Interface (FFI) is called
   NativeBoost and will move more logic into Smalltalk
   itself. So you dont have to write/compile a plugin.
 
   You just need a VM with NativeBoost support (NBCog.exe on Windows)
 
   Using native Boost (when in Pharo 2.0) you can (already!)
   write:
 
 NBWin32Window getFocus setWindowText: 'Hello using Native Boost'
 
   to change the window title. Internally I just call the
   Windows Win32-API function SetWindowTextA using the
   window handle.
 
   If someone from other platforms implements an NBUnixWindow,
   NBMacWindow, NBRiscOSWindow, ... we can also implement a
   common interface class (NBPharoWindow for example).
 
  Hope this helps a little bit
 
  Bye
  T.
 

 I downloaded the NBCog.exe and was able to execute the 'NBWin32Window
 getFocus setWindowText: 'Hello using Native Boost' example you showed
 above. It looks me to like they are direct calls to the Windows API
 which don't require any external DLLs other the built in Windows
 ones..

 However on Linux would that mean it may be necessary to use different
 code for Gnome or KDE/Qt for instance, or use some other native or
 crossplatform widgetset like Wx?


IIRC no.  This is at the XLib level.  See XStoreName/XSetTextProperty.
-- 
best,
Eliot

Re: [Pharo-project] NativeBoost design and deployment

[Eliot Miranda]

On Wed, Jan 9, 2013 at 12:10 AM, Igor Stasenko siguc...@gmail.com wrote:

 On 8 January 2013 19:38, Eliot Miranda eliot.mira...@gmail.com wrote:
 
 
 
  On Fri, Jan 4, 2013 at 12:37 AM, Igor Stasenko siguc...@gmail.com
 wrote:
 
  On 4 January 2013 08:54, Torsten Bergmann asta...@gmx.de wrote:
   When one deploys an image one usually requires ONLY
   the image - not the source or changes file. An image locker
   code would look like this:
  
 SmalltalkImage checkSourcesFileAvailability: false.
 SmalltalkImage checkChangesFileAvailability: false
  
   do disable acording warnings when source/changefile is removed.
  
   If one uses NativeBoost in such a deployment scenario, for
   instance the
  
 NBWin32Shell shellBrowse: 'http://www.google.de'
  
   functionality the internal code (due to missing source) now
   looks like this
  
 shellExecute: t1 file: t2 parameters: t3 directory: t4 show: t5
   primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'
   ^ self nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR
   #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR
   #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll'
  
   Hence the t1 ... t5 parameters.
  
   NativeBoost is in this situation not able to match the
   FFI parameters and throws an error Could not find accessor for
 variable
   ...
  
   Try yourself without a changes and source file. This makes
   NativeBoost not very deployment friendly and unusable in
   such a minimal deployment scenario ...
  
   Any comments?
  
 
  yes it needs sources (indirectly) to bind method's argument names
  during code generation.
  To avoid that, i can imagine that one must modify a compiler to detect
  if compiled method
  primitive requires arg names, and store them in method properties.
  Like that later code generator can use them without need to access the
  source code.
 
 
  Indeed.  If a pragma were used then the whole thing could look a lot
 nicer,
  not be dependent on source, and include support for an error code.  e.g.
 
  shellExecute: lpOperation file: lpFile parameters: lpParameters
 directory:
  lpDirectory show: nShowCmd
 
  nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR
 #lpOperation #,
  #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR #lpDirectory #,
 #INT
  #nShowCmd ) )
module: 'Shell32.dll'
errorCode: ec
 
  ^self nbCallFailedWith: ec
 
  It's pretty trivial to add such pragma compilers to the compiler.  There
 is
  an example for the FFI.  It also frees one to use a nicer syntax, e.g.
 
  shellExecute: lpOperation file: lpFile parameters: lpParameters
 directory:
  lpDirectory show: nShowCmd
  nbCall: 'HINSTANCE ShellExecuteA(0, LPCTSTR lpOperation, LPCTSTR
  lpFile, LPCTSTR lpParameters, LPCTSTR lpDirectory, INT nShowCmd)'
module: 'Shell32.dll'
errorCode: ec
 
  ^self nbCallFailedWith: ec
 

 i do not see how encoding function signature in pragma could help with
 binding argument names.


Because your pragma processing code can add additional state, i.e. the map
form input argument order to call argument order.


 Yes, you need to get some control at compile time to be able to encode
 method arg names somewhere in method properties for later use.. but
 not at cost of moving everything into pragma.


What's this cost?  The call info has to live somewhere.



 And 'nice' syntax is actually already there .. nothing prevents you
 from using strings for function signature, e.g.

 self nbCall: 'int foo()'
 equivalent to
 self nbCall: #(int foo() )

 (i don't know why Torsten gave code in such form, that could leave an
 impression that syntax is horrible ;)

 And besides, how you suppose to pragmatize following:

 storeDouble: aDouble at: address
  This method stores a double floating point value at given memory
 address.
 an address can be an instance of NBExternalAddress, or
 simple ByteArray with at least 8 bytes long, which will hold a
 64bit
 floating-point value

 primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'
 error: errorCode

 ^ self nbCallout
  options: #(
 - optCoerceNilToNull
 + optAllowByteArraysPtr
 + optAllowExternalAddressPtr
 );
 function: #( void (void * address, double aDouble) )
 emit: [:gen |  | asm |
 asm := gen asm.

 Here , we expecting that an address value is on
 top of the stack
 asm
 pop: EDX;  load an address value into EDX
 register by popping it
 from a stack

 now copy the floating point value (which
 is 8-bytes long) to the
 given address
 mov: ESP ptr to: EAX;
 mov: EAX to: EDX ptr;   store first

Re: [Pharo-project] NativeBoost design and deployment

[Eliot Miranda]

On Fri, Jan 4, 2013 at 12:37 AM, Igor Stasenko siguc...@gmail.com wrote:

 On 4 January 2013 08:54, Torsten Bergmann asta...@gmx.de wrote:
  When one deploys an image one usually requires ONLY
  the image - not the source or changes file. An image locker
  code would look like this:
 
SmalltalkImage checkSourcesFileAvailability: false.
SmalltalkImage checkChangesFileAvailability: false
 
  do disable acording warnings when source/changefile is removed.
 
  If one uses NativeBoost in such a deployment scenario, for
  instance the
 
NBWin32Shell shellBrowse: 'http://www.google.de'
 
  functionality the internal code (due to missing source) now
  looks like this
 
shellExecute: t1 file: t2 parameters: t3 directory: t4 show: t5
  primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'
  ^ self nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR
 #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR
 #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll'
 
  Hence the t1 ... t5 parameters.
 
  NativeBoost is in this situation not able to match the
  FFI parameters and throws an error Could not find accessor for variable
 ...
 
  Try yourself without a changes and source file. This makes
  NativeBoost not very deployment friendly and unusable in
  such a minimal deployment scenario ...
 
  Any comments?
 

 yes it needs sources (indirectly) to bind method's argument names
 during code generation.
 To avoid that, i can imagine that one must modify a compiler to detect
 if compiled method
 primitive requires arg names, and store them in method properties.
 Like that later code generator can use them without need to access the
 source code.


Indeed.  If a pragma were used then the whole thing could look a lot nicer,
not be dependent on source, and include support for an error code.  e.g.

shellExecute: lpOperation file: lpFile parameters: lpParameters directory:
lpDirectory show: nShowCmd
nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR #lpOperation
#, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR #lpDirectory #,
#INT #nShowCmd ) )
  module: 'Shell32.dll'
  errorCode: ec

^self nbCallFailedWith: ec

It's pretty trivial to add such pragma compilers to the compiler.  There is
an example for the FFI.  It also frees one to use a nicer syntax, e.g.

shellExecute: lpOperation file: lpFile parameters: lpParameters directory:
lpDirectory show: nShowCmd
nbCall: 'HINSTANCE ShellExecuteA(0, LPCTSTR lpOperation, LPCTSTR
lpFile, LPCTSTR lpParameters, LPCTSTR lpDirectory, INT nShowCmd)'
  module: 'Shell32.dll'
  errorCode: ec

^self nbCallFailedWith: ec


  Thanks
  T.



 --
 Best regards,
 Igor Stasenko




-- 
best,
Eliot

[Pharo-project] New Cog VMs available...

[Eliot Miranda]

...at http://www.mirandabanda.org/files/Cog/VM/VM.r2662/.

CogVM binaries as per VMMaker.oscog-eem.251/r2662

Give primitiveRemLargeIntegers primitive # 20.

Add yet another libc line to the linux launch script(s), and try and make
the
script suggest users extend it themselves.  you can lead a horse to water...

Fix (old) bug in ssAllocateRequiredRegMask:upThrough:
that would flush entire stack if allocating any register.

Implement absent receiver sends in the Newspeak Cogit.

On Mac turn off inlining when compiling the Cogit.  The Cogit's runtime is
negligible and we prefer to save space.  With the recent changes (better
shift
code??) the VM appears faster anyway.

Integrate directed shift changes from cog issue 111 that affect the
CoInterpreter and Cogit.

Make the translated primitive plugins include info from their
primitive supplying classes.

Integrate changes from VMMaker-dtl.293 which useshifts
in place of slower bitShift: code in plugins.
Add width failure cases to BMPReadWriterPlugin read  write 24Bmp prims.

Integrate issue 115.  Fix FFIPlugin/ThreadedFFIPlugin unsignedShortAt:.

-- 
Happy New Year everyone,
Eliot

Re: [Pharo-project] New Cog VMs available...

[Eliot Miranda]

...and at http://www.mirandabanda.org/files/Cog/VM/VM.r2664.

CogVM binaries as per VMMaker.oscog-eem.252/r2664.

Issue 117.  Fix primitiveRemLargeIntegers.
The result should be negated iff receiver negative.


On Tue, Jan 8, 2013 at 3:28 PM, Eliot Miranda eliot.mira...@gmail.comwrote:

 ...at http://www.mirandabanda.org/files/Cog/VM/VM.r2662/.

 CogVM binaries as per VMMaker.oscog-eem.251/r2662

 Give primitiveRemLargeIntegers primitive # 20.

 Add yet another libc line to the linux launch script(s), and try and make
 the
 script suggest users extend it themselves.  you can lead a horse to
 water...

 Fix (old) bug in ssAllocateRequiredRegMask:upThrough:
 that would flush entire stack if allocating any register.

 Implement absent receiver sends in the Newspeak Cogit.

 On Mac turn off inlining when compiling the Cogit.  The Cogit's runtime is
 negligible and we prefer to save space.  With the recent changes (better
 shift
 code??) the VM appears faster anyway.

 Integrate directed shift changes from cog issue 111 that affect the
 CoInterpreter and Cogit.

 Make the translated primitive plugins include info from their
 primitive supplying classes.

 Integrate changes from VMMaker-dtl.293 which useshifts
 in place of slower bitShift: code in plugins.
 Add width failure cases to BMPReadWriterPlugin read  write 24Bmp prims.

 Integrate issue 115.  Fix FFIPlugin/ThreadedFFIPlugin unsignedShortAt:.

 --
 Happy New Year everyone,
 Eliot




-- 
best,
Eliot

Re: [Pharo-project] About (backwards) Compatibility

[Eliot Miranda]

On Sat, Dec 15, 2012 at 3:42 PM, Sean P. DeNigris s...@clipperadams.comwrote:

 H. Hirzel wrote
  As Chris points out, the difference is minimal.
 
  Sean, it looks like you need better examples to show how you perceive
  the benefits of the FileSystem design

 While you ignored the point of my followup post, which is that beauty and
 simplicity lead to more than the sum of a few keywords, here are a few
 basic
 examples...

 Example #1:
 file := FileDirectory directoryEntryFor: '/path/to/file'.
 FileDirectory extensionFor: file name.

 vs.

 file2 := '/path/to/file' asFileReference.
 file2 extension.

 #2:
 (FileDirectory on: 'path') entryAt: 'nohup.out'.
 vs.
 'path' asFileReference / 'filename'

 Most operations routed through one massive FD class vs. immediate access
 to the domain object you want; not to mention the appreciated absence of
 parens.

 No difference??

 But with

String methods for *FileSystem-utilities
/ aPath
  ^self asFileReference / aPath

you get

'path' / 'filename'

and that's *really* nice.

Does anyone think that '123' / '45' is good??

This is a compromise:

/ arg
self size = 0 ifTrue: [self error: 'cannot coerce the empty string].
^('+-01234456789' incudes: self first)
ifTrue: [arg adaptToString: self andSend: #/]
ifFalse: [self asFileReference / arg]

the issue here being whether FileSystem wants '.profile' or '.hg' et al or
math wants '.123'.

If FileSystem provides path-name checking then the above could include a
specific legality check instead of the naive discrimination.

Personally I find the prospect of a concise file scripting api much more
appealing than lazy numeric conversion.  The absence of the former is why
so much of my life involves bash scripts.  The latter isn't necessary if
one starts off with numbers in the first place, and being literals they're
as easy, no, easier than denoting numbers using strings (1 + 1 is shorter
than '1' + 1).

I hope Squeak integrates FileSystem in 4.4 for 4.5.
-- 
best,
Eliot

Re: [Pharo-project] about isAbstractClass

[Eliot Miranda]

On Mon, Dec 17, 2012 at 10:41 AM, Andrew P. Black bl...@cs.pdx.edu wrote:

 Two things make a class abstract.

 One is that it has methods that a subclass *must* override — that is
 captured by #hasAbstractMethods.

 The other is that the class cannot be instantiated — normally because it
 has overridden new.
 It can be the case that an abstract class defines only CONCRETE methods
 for its subclasses, but still is abstract.  So, it seems to me that
 #isAbstractClass is not subsumed by #hasAbstractMethods.

 A trait AbstactClassT could define #new to be self error: 'Class ' ,
 self name , ' is abstract and cannot be instantiated' and #isAbstractClass
 to be ^ true.


+3.



 Andrew


 On Sun, Dec 16, 2012 at 11:03 PM, Stéphane Ducasse
 stephane.duca...@inria.fr wrote:

 Good suggestion I will change it to hasAbstractMethods it looks much
 better.

 Tx for the suggestion.


 what about 'additionalAbstractMethods' that would return the list of
 new abstract methods the class  defines.





-- 
best,
Eliot

[Pharo-project] New Cog VMs available

[Eliot Miranda]

New Cog VMs available at http://www.mirandabanda.org/files/Cog/VM/VM.r2637/.

CogVM binaries as per VMMaker.oscog-eem.238/r2637

Restore ThreadedFFIPlugin wanting COGMTVM to be determined on
command line.  Probably broke in VMMaker.oscog-eem.218

Fix bug in changeClass:from: so that if receiver has long header and
class is compact, receiver still gets compact class field set, not
cleared.  No matter what header an instance has, if its class is
compact it should have the compact class index set.
-- 
best,
Eliot

[Pharo-project] new Cog VMs available

[Eliot Miranda]

Hi All,

new Cog VMs available at
http://www.mirandabanda.org/files/Cog/VM/VM.r2636/.  The main change here
is to do with corrected headroom and safer signal handling which should
hopefully improve stability on linux.

Cog VM binaries as per VMMaker.oscog-eem.234/r2636/r2638.

Use the -z now link flag on the linux builds.  This causes the dynamic linker
to resolve unresolved symbols on load instead of lazily.  This affects
reliability in signal handlers, because if the dynamic linker can run at any
time it can therefore run in a signal handler and cause a deep call chain which
could corrupt a stack page in the JIT.
So this aplies three fixes to this issue:
a) correct the stack headroom determination
b) use sigaltstack for signal handlers in the UnixOSProcessPlugin
c) link using -z now on linux.

Use SA_ONSTACK/sigaltstack for signal handlers installed by the
UnixOSProcessPlugin to avoid running signal handlers on the JIT's stack.
(r2638: Check for needing sigaltstack properly in setSignalNumber:handler:).


VMMaker.oscog-eem.233/r2632

Rename misnamed internalIsMutable: and internalIsImmutable:
to isOopMutable: and isOopImmutable:.  Affects sqVirtualMachine.c,
but only part of api used in Newspeak VMs.

Merge LargeInteger primitive fixes from VMMaker-dtl.286 and
tests from VMMaker-dtl.289.

UnixOSProcessPlugin:
Merge with VMConstruction-Plugins-OSProcessPlugin-dtl.35.
In particular restore missing code to forwardSignal:toSemaphoreAt:

Get plugin to use SA_ONSTACK/sigaltstack for signal handlers
if loaded in the JIT.


VMMaker.oscog-eem.230/r2631

Fix stackPage headroom calculation in CoInterpreter.  Was getting
things backward.  This increases the stack page headroom by 62%
from 1564 bytes to 2532 bytes.  Shootout benchmarks unchanged,
so reduction in frames per page is not an issue for typical code.

This should result in fewer crashes on linux where the dynamic
linker, if it kicked in during a signal handler, could cause a deep
call chain at interrupt time and trample the start of the adjoining
stack page.

Merge LargeInteger primitive fixes from VMMaker-dtl.286.

Change generation of plugin code so that internal plugins call VM
routines directly and external plugins call through their own local
copies of the function pointers in InterpreterProxy.  External plugins
copy the InterpreterProxy functions to their local copies in
setInterpreter:.

Change implementations of stObject:at:put: to return their value, to
match the declaration in InterpreterProxy.

Streamline ObjectMemoryinstantiateClass:indexableSize: (hdrSize
and header3 change together).

Optimize the debug VM by making startOfMemory a macro that
answers heapBase instead of a method.

Improve stack page printing, and make stack trace printing more
robust (findClass/SelectorOfMethod:forReceiver:).

Make temporary:in:put: et al answer their values. For stObject:at:put:.

Make jumpTable size err message more explanatory.

Rename misnamed internameIsMutable: and internalIsImmutable:
to isOopMutable: and isOopImmutable:.  Affects sqVirtualMachine.c,

but only part of api used in Newspeak VMs.--
best,
Eliot

Re: [Pharo-project] Is the plugin JoystickTabletPlugin of the CogVM package working?

[Eliot Miranda]

Hi Carla,


On Thu, Dec 13, 2012 at 7:15 AM, Carla F. Griggio
carla.grig...@gmail.comwrote:

 Hello!
 Does anybody know if the JoystickTabletPlugin is actually working for
 Pharo? I'm trying to use it with CogVM with no success :( I see
 in InputEventHandler that there is support for pen tablets using this
 plugin but I can't manage to make it work. As it comes in the CogVM package
 I assume that somebody put it there because it works, but I keep getting
 PrimitiveFailed error messages wether I have a tablet connected or not.

 The external plugins of the CogVM are supposed to work without me doing
 anything? Just executing the VM? Or do I have to activate them somehow?

 Sorry for keep bothering with this :$ And thanks!


the Qwaq VM, which became the Cog fork disabled the joystick plugin.  We
can try and ressurect it but I'm not sure what is involved.  What platform
are you on?

-- 
best,
Eliot

Re: [Pharo-project] Protecting against stack overflow ?

[Eliot Miranda]

On Tue, Dec 11, 2012 at 9:26 PM, Igor Stasenko siguc...@gmail.com wrote:

 On 12 December 2012 00:43, Eliot Miranda eliot.mira...@gmail.com wrote:
 
 
 
  On Tue, Dec 11, 2012 at 3:35 PM, Eliot Miranda eliot.mira...@gmail.com
  wrote:
 
 
 
 
  On Tue, Dec 11, 2012 at 10:26 AM, Igor Stasenko siguc...@gmail.com
  wrote:
 
  hehe..
  it looks like we can do it:
 
   - when memory hits the waterline mark, VM should do the following:
 - for every currently scheduled process , push an artificial stack
  frame on top , which is
  StackOverflow signal.
 
 
  If the VM supports the LowSpaceSignal mechanism as it used to be then
 this
  can be done in the image with a high-priority process.  And tehrefore
 it can
  e.g. be avoided for processes such as the Delay process, where IMO it is
  inappropriate.
 
 
  And if it is done in the image it is easy to e.g. avoid pushing two such
  frames on the same process because the process has made no progress since
  the last occurrence, etc.
 
 indeed.. i did not realized that this can be done inside an image :)

 i was thinking more about stack limit, not space limit.
 because scanning the stack will trigger putting all contexts on heap
 (which in own turn will put even more pressure on memory).. while in
 VM, to determine stack depth, it can walk the stack frames without
 marrying them with heap contexts to count stack depth.
 or it is not the case? is accessing the context state triggers
 marrying it with heap object, i.e.

 [ count := count + 1. context := context sender. ] whileNotNil

 ?


exactly. The VM can provide a primitive to walk the stack without creating
objects (which worsens the space situation).  Even better the VM could
maintain stack depth in Process, but that's for the future, because it
needs a) a slot in Process and b) the support writing in both VMs.

--
 Best regards,
 Igor Stasenko.




-- 
best,
Eliot

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

[Eliot Miranda]

On Tue, Dec 11, 2012 at 8:58 AM, adrians nman...@gmail.com wrote:



 Of course not all of what needs to be done in Pharo should be of at same
 priority. It makes sense to first fix the tools one uses for fixing
 everything else, so that one can speed up one's own work and at the same
 time open up the possibility for others (less skilled) to help out.

 In any case I'm sorry if it seems that I'm demanding you or anyone else
 should make this a higher priority. The thinking was that maybe there is
 someone (Stephane D?) who, to some degree, can prioritize certain things
 over others and if so, wouldn't it make sense to fix the most basic tool
 that is used to help fix everything else?

 Who knows though, maybe the debugger is not often used by the experts.


On the contrary.  Many experts program in the debugger (one defines a
method when one gets a doesNotUnderstand:).  Many experts use the debugger
to explore code (running code is a powerful aid to understanding).  Some
experts use the simulation machinery that underlies the debugger to do
things like partial evaluation for type analysis etc.


 -- Adrian



 --
 View this message in context:
 http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4658666p4658877.html
 Sent from the Pharo Smalltalk mailing list archive at Nabble.com.




-- 
best,
Eliot

Re: [Pharo-project] Protecting against stack overflow ?

[Eliot Miranda]

On Tue, Dec 11, 2012 at 2:44 AM, Sven Van Caekenberghe s...@stfx.eu wrote:

 Hi Eliot,

 On 11 Dec 2012, at 02:33, Eliot Miranda eliot.mira...@gmail.com wrote:

  2012/12/9 Sven Van Caekenberghe s...@stfx.eu
  Hi,
 
  Would it be possible to build some kind of protection against stack
 overflow ?
 
  note that there already is some mechanism.  The low space mechanism is
 supposed to protect against stack overflow but with today's memories and
 the difficulty of testing it, this mechanism often a) takes way too long to
 kick in, and b) either leaves the system in a very sluggish state or simply
 fails to kick in and the system crashes with an out-of-memory error.
 
  Part of the problem is in designing a mechanism which is in keeping with
 the reflective nature of the system.  What I mean is that we now have two
 different VMs, the Interpreter and the STack/Cog VMs.  First one wants a
 check which is cheap.  That means a check which isn't run on every send.
  In the interpreter a natural time to check for recursion would be on e.g.
 fullGC, checking for repetition in the current process's context chain.
  The the Stack/Cog VMs the natural time is on evacuating a stack page when
 the stack zone is full.  But these are two different mechanisms, both of
 which are deep in the VM, neither of which can be conveniently intercepted
 from Smalltalk, unlike e.g. doesNotUnderstand:.
 
  Personally I like the idea of reviving the low space mechanism and
 maintaining it properly.  For example, if the low space mechanism causes
 the low space semaphore to fire often, because the limit was set only a
 little way above the current memory size, and not, as it is now, a little
 below the absolute limit, then when it fires, the low space process could
 inspect the current process's stack (e.g. via accelerated via a primitive
 for performance) and see how deep it is, and possibly whether there is
 recursion (e.g. a bag of context methods would soon reveal high-frequency
 methods, and then those contexts could be inspected for repetition, but
 KISS says just have a per-process limit on the maximum depth of stack).

 Thanks for the reply.

 Yes, getting a low space warning sooner and then deal with that
 intelligently at the image level sounds like a good solution. It is
 probably more portable, requires miminal VM collaboration, allows for many
 behaviours as a reaction and would catch other problems than just stack
 overflow.

 Is this already possible today ?


Wow, I'm amazed.  The low space limit in the VM has been ripped out  So no,
it is not possible, but it would be easy to put back.  There is a variable
in ObjectMemory (the VM's heap manager/garbage collector class) that
defines the low-space limit, but there is no setter.  Back in the day (and
still in VisualWorks) there was a primitive

SystemDictionary methods for memory space
signal: aSemaphore atOopsLeft: numOops wordsLeft: numWords
Tell the object memory to signal the Semaphore when either the number
 of object pointers remaining drops below numOops, or the number of
words in the object space remaining drops below numWords.  Fail if the
frist argument is neither a Semaphore nor nil.  Fail if numOops is not a
16-bit Integer, or if numWords is not a 32-bit LargePositiveInteger.
Essential.  See Object documentation whatIsAPrimitive.

primitive: 116
self primitiveFailed

But this and its support is gone.  Hmm.  Hmmph :)




 Preferrably, dynamic control over the limit would be nice: in a headless
 server you want other behavior than during interactive development.


Right.  The low space process would readjust the value every time low space
fired.  But one could (can) call the primitive at any time to install a new
limit.


 Sven

  This is actually the most common situation for loop/cycle that either
 results in an unusable image or a crash.
  Interrupting with CMD-. is not always possible.
  A possible solution could be to just limit the stack size and throw an
 exception.
 
  For example, in LispWorks, it goes like this:
 
  CL-USER 5  (defun foo () (cons (random 100) (foo)))
  FOO
 
  CL-USER 6  (foo)
 
  Stack overflow (stack size 48128).
1 (continue) Extend stack by 50%.
2 (abort) Return to level 0.
3 Return to top loop level 0.
 
  Type :b for backtrace or :c option number to proceed.
  Type :bug-form subject for a bug report template or :? for other
 options.
 
  CL-USER 7 : 1  :bq
 
  ERROR - RUNTIME:BAD-ARGS-OR-STACK - LENGTH - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO
  - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
  - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
  - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
  - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
  - FOO - FOO - FOO - FOO - FOO - FOO

Re: [Pharo-project] Protecting against stack overflow ?

[Eliot Miranda]

On Tue, Dec 11, 2012 at 10:26 AM, Igor Stasenko siguc...@gmail.com wrote:

 hehe..
 it looks like we can do it:

  - when memory hits the waterline mark, VM should do the following:
- for every currently scheduled process , push an artificial stack
 frame on top , which is
 StackOverflow signal.


If the VM supports the LowSpaceSignal mechanism as it used to be then this
can be done in the image with a high-priority process.  And tehrefore it
can e.g. be avoided for processes such as the Delay process, where IMO it
is inappropriate.



 Then the first thing what this guy should do, when he will get
 control, is to analyze
 how deep is the stack of given process and if it surpassed the allowed
 threshold,
 and if there's no handler, then decide whether to kill the process or not.

 Also, since it is exception, a user code can intercept this exception and
 either ignore it (effectively forcing system to keep running), or otherwise
 terminate process, but in an educated manner, since he might have a
 better knowledge,
 what can eat so much resources in his code.. as well, as do a gracious
 failure
 handling, e.g., correctly clean associated system resources etc.


 --
 Best regards,
 Igor Stasenko.




-- 
best,
Eliot

Re: [Pharo-project] Protecting against stack overflow ?

[Eliot Miranda]

On Tue, Dec 11, 2012 at 3:33 PM, Eliot Miranda eliot.mira...@gmail.comwrote:




 On Tue, Dec 11, 2012 at 2:44 AM, Sven Van Caekenberghe s...@stfx.euwrote:

 Hi Eliot,

 On 11 Dec 2012, at 02:33, Eliot Miranda eliot.mira...@gmail.com wrote:

  2012/12/9 Sven Van Caekenberghe s...@stfx.eu
  Hi,
 
  Would it be possible to build some kind of protection against stack
 overflow ?
 
  note that there already is some mechanism.  The low space mechanism is
 supposed to protect against stack overflow but with today's memories and
 the difficulty of testing it, this mechanism often a) takes way too long to
 kick in, and b) either leaves the system in a very sluggish state or simply
 fails to kick in and the system crashes with an out-of-memory error.
 
  Part of the problem is in designing a mechanism which is in keeping
 with the reflective nature of the system.  What I mean is that we now have
 two different VMs, the Interpreter and the STack/Cog VMs.  First one wants
 a check which is cheap.  That means a check which isn't run on every send.
  In the interpreter a natural time to check for recursion would be on e.g.
 fullGC, checking for repetition in the current process's context chain.
  The the Stack/Cog VMs the natural time is on evacuating a stack page when
 the stack zone is full.  But these are two different mechanisms, both of
 which are deep in the VM, neither of which can be conveniently intercepted
 from Smalltalk, unlike e.g. doesNotUnderstand:.
 
  Personally I like the idea of reviving the low space mechanism and
 maintaining it properly.  For example, if the low space mechanism causes
 the low space semaphore to fire often, because the limit was set only a
 little way above the current memory size, and not, as it is now, a little
 below the absolute limit, then when it fires, the low space process could
 inspect the current process's stack (e.g. via accelerated via a primitive
 for performance) and see how deep it is, and possibly whether there is
 recursion (e.g. a bag of context methods would soon reveal high-frequency
 methods, and then those contexts could be inspected for repetition, but
 KISS says just have a per-process limit on the maximum depth of stack).

 Thanks for the reply.

 Yes, getting a low space warning sooner and then deal with that
 intelligently at the image level sounds like a good solution. It is
 probably more portable, requires miminal VM collaboration, allows for many
 behaviours as a reaction and would catch other problems than just stack
 overflow.

 Is this already possible today ?


Um, ignore this.  I was smoking something.  (actually the message selector
browser completely hid the inst var access browser so I didn't see the inst
var accesses).  Hang on and I'll try again...



 Wow, I'm amazed.  The low space limit in the VM has been ripped out  So
 no, it is not possible, but it would be easy to put back.  There is a
 variable in ObjectMemory (the VM's heap manager/garbage collector class)
 that defines the low-space limit, but there is no setter.  Back in the day
 (and still in VisualWorks) there was a primitive

 SystemDictionary methods for memory space
 signal: aSemaphore atOopsLeft: numOops wordsLeft: numWords
 Tell the object memory to signal the Semaphore when either the number
  of object pointers remaining drops below numOops, or the number of
 words in the object space remaining drops below numWords.  Fail if the
  frist argument is neither a Semaphore nor nil.  Fail if numOops is not a
 16-bit Integer, or if numWords is not a 32-bit LargePositiveInteger.
  Essential.  See Object documentation whatIsAPrimitive.

 primitive: 116
 self primitiveFailed

 But this and its support is gone.  Hmm.  Hmmph :)




 Preferrably, dynamic control over the limit would be nice: in a headless
 server you want other behavior than during interactive development.


 Right.  The low space process would readjust the value every time low
 space fired.  But one could (can) call the primitive at any time to install
 a new limit.


 Sven

  This is actually the most common situation for loop/cycle that either
 results in an unusable image or a crash.
  Interrupting with CMD-. is not always possible.
  A possible solution could be to just limit the stack size and throw an
 exception.
 
  For example, in LispWorks, it goes like this:
 
  CL-USER 5  (defun foo () (cons (random 100) (foo)))
  FOO
 
  CL-USER 6  (foo)
 
  Stack overflow (stack size 48128).
1 (continue) Extend stack by 50%.
2 (abort) Return to level 0.
3 Return to top loop level 0.
 
  Type :b for backtrace or :c option number to proceed.
  Type :bug-form subject for a bug report template or :? for other
 options.
 
  CL-USER 7 : 1  :bq
 
  ERROR - RUNTIME:BAD-ARGS-OR-STACK - LENGTH - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO
  - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO
  - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO

Re: [Pharo-project] Protecting against stack overflow ?

[Eliot Miranda]

On Tue, Dec 11, 2012 at 3:35 PM, Eliot Miranda eliot.mira...@gmail.comwrote:




 On Tue, Dec 11, 2012 at 10:26 AM, Igor Stasenko siguc...@gmail.comwrote:

 hehe..
 it looks like we can do it:

  - when memory hits the waterline mark, VM should do the following:
- for every currently scheduled process , push an artificial stack
 frame on top , which is
 StackOverflow signal.


 If the VM supports the LowSpaceSignal mechanism as it used to be then this
 can be done in the image with a high-priority process.  And tehrefore it
 can e.g. be avoided for processes such as the Delay process, where IMO it
 is inappropriate.


And if it is done in the image it is easy to e.g. avoid pushing two such
frames on the same process because the process has made no progress since
the last occurrence, etc.




 Then the first thing what this guy should do, when he will get
 control, is to analyze
 how deep is the stack of given process and if it surpassed the allowed
 threshold,
 and if there's no handler, then decide whether to kill the process or not.

 Also, since it is exception, a user code can intercept this exception and
 either ignore it (effectively forcing system to keep running), or
 otherwise
 terminate process, but in an educated manner, since he might have a
 better knowledge,
 what can eat so much resources in his code.. as well, as do a gracious
 failure
 handling, e.g., correctly clean associated system resources etc.


 --
 Best regards,
 Igor Stasenko.




 --
 best,
 Eliot




-- 
best,
Eliot

Re: [Pharo-project] Protecting against stack overflow ?

[Eliot Miranda]

2012/12/9 Sven Van Caekenberghe s...@stfx.eu

 Hi,

 Would it be possible to build some kind of protection against stack
 overflow ?


note that there already is some mechanism.  The low space mechanism is
supposed to protect against stack overflow but with today's memories and
the difficulty of testing it, this mechanism often a) takes way too long to
kick in, and b) either leaves the system in a very sluggish state or simply
fails to kick in and the system crashes with an out-of-memory error.

Part of the problem is in designing a mechanism which is in keeping with
the reflective nature of the system.  What I mean is that we now have two
different VMs, the Interpreter and the STack/Cog VMs.  First one wants a
check which is cheap.  That means a check which isn't run on every send.
 In the interpreter a natural time to check for recursion would be on e.g.
fullGC, checking for repetition in the current process's context chain.
 The the Stack/Cog VMs the natural time is on evacuating a stack page when
the stack zone is full.  But these are two different mechanisms, both of
which are deep in the VM, neither of which can be conveniently intercepted
from Smalltalk, unlike e.g. doesNotUnderstand:.

Personally I like the idea of reviving the low space mechanism and
maintaining it properly.  For example, if the low space mechanism causes
the low space semaphore to fire often, because the limit was set only a
little way above the current memory size, and not, as it is now, a little
below the absolute limit, then when it fires, the low space process could
inspect the current process's stack (e.g. via accelerated via a primitive
for performance) and see how deep it is, and possibly whether there is
recursion (e.g. a bag of context methods would soon reveal high-frequency
methods, and then those contexts could be inspected for repetition, but
KISS says just have a per-process limit on the maximum depth of stack).


 This is actually the most common situation for loop/cycle that either
 results in an unusable image or a crash.
 Interrupting with CMD-. is not always possible.
 A possible solution could be to just limit the stack size and throw an
 exception.

 For example, in LispWorks, it goes like this:

 CL-USER 5  (defun foo () (cons (random 100) (foo)))
 FOO

 CL-USER 6  (foo)

 Stack overflow (stack size 48128).
   1 (continue) Extend stack by 50%.
   2 (abort) Return to level 0.
   3 Return to top loop level 0.

 Type :b for backtrace or :c option number to proceed.
 Type :bug-form subject for a bug report template or :? for other
 options.

 CL-USER 7 : 1  :bq

 ERROR - RUNTIME:BAD-ARGS-OR-STACK - LENGTH - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - FOO
 - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO - FOO -
 FOO - FOO - FOO - FOO - FOO - FOO - 

Re: [Pharo-project] [squeak-dev] New Cog VMs available

[Eliot Miranda]

Hi Blake,

On Mon, Dec 3, 2012 at 7:10 AM, Blake McBride bl...@mcbride.name wrote:

 Greetings,

 I tried to integrate Squeak to a C based application more than six years
 ago.  The project failed because we were not able to have our application
 call Squeak, then have Squeak call the application, and then the
 application call Squeak again recursively.  An analysis of the Squeak VM
 revealed a kernel design consisting of a lot of global variables - quite
 unnecessarily.  The unnecessary use of global variables over a localized
 structure for example unnecessarily prevented the use of Squeak as an
 extension language (unless you had no recursion).  I spent several days
 trying to re-structure the Squeak kernel but I kept running into problems
 and just ran out of time.

 As a side note, that company I was with ended up making a lot of
 investment in Scheme because we were easily able to integrate that language
 with our application.  Now, not only is Scheme used heavily within that
 company but many of their clients use it too to customize their application.

 This brings me to my question, is COG reentrant?


Yes it is.  It supports call-outs and call-ins.  But currently there is no
support for Cog to be packaged as a DLL.  You have to start by calling C
from Squeak.



  If not, as the author of COG, I would think it relatively easy to
 restructure it to be so.  Such a design capability can make a huge
 difference to COG's acceptance to many.  It may even be the reason to
 switch to COG.


Yes indeed.   The issue is of course funding to spend the time to make the
necessary changes.


 Just sharing some thoughts.  Thanks.

 Blake McBride

 On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda eliot.mira...@gmail.comwrote:

 ...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.

 These fix a bug with pc mapping that could cause the Vm to crash on
 simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i|
 1=1]).  They also cause the instantiation primitives to pop all their
 arguments rather than assume their argument count is 0 or 1.  More change
 info available in the directory.
 --
 best,
 Eliot











-- 
best,
Eliot

Re: [Pharo-project] using a long running native thread - NativeBoost or Plugin?

[Eliot Miranda]

On Sun, Dec 2, 2012 at 2:59 PM, drush66 davorin.rusevl...@gmail.com wrote:

 Would it be possible to start native thread inside pharo? This thread would
 run (for quite a long time) some event loop (like the libev), and post some
 info to the SharedQueue. Smalltalk code would in turn be reading stuff from
 this queue. You could say it would be pumping events from libev to
 SharedQueue instance for Smalltalk code to consume.

 Is this doable? With NativeBoost or Plugin?

 I have also found some info on threaded VM, but if I understand it
 correctly
 it seems more oriented to provide a thread to execute FFI call on it.


I wouldn't say that.  The threading scheme is David Simmons' architecture,
used in his AOS and S# VMs and similar to that used in the python VM, but
more efficient.  It allows multiple threads to share the VM, but only
allows one to run Smalltalk at any one time.  It is designed to allow
Smalltalk to interact freely with any number of native threads.  Cal-backs
can come in from any thread.  SMalltalk processes can be associated with
specific threads, allowing one to control which thread a call-out is made
on.

-
 http://www.cloud208.com/
 --
 View this message in context:
 http://forum.world.st/using-a-long-running-native-thread-NativeBoost-or-Plugin-tp4657747.html
 Sent from the Pharo Smalltalk mailing list archive at Nabble.com.




-- 
best,
Eliot

Re: [Pharo-project] CogVM crash code

[Eliot Miranda]

thanks, Jon.  Good one!

On Fri, Nov 30, 2012 at 9:07 AM, Jon Anderson jonkander...@gmail.comwrote:

 !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012
 17:26'!
 crashCogVM
  Evaluate [
 nil crashCogVM ]

 | i |
 i := 20.
 1 to: i do: [:d | 1-1 ]
 ! !




-- 
best,
Eliot

Re: [Pharo-project] CogVM crash code

[Eliot Miranda]

OK, this is fixed.  Thanks, Jon.  The bug was that the pop of the folded
constant did not record the implicit send in the folding, hence pc mapping
was wrong.  i.e. 1-1 gets folded away to 0, and the code generator marks
the result 0 as being the result of a send, but then the result gets
discarded (when it is popped) without being noted in the pc map.  In the
machine code there needs to be at least a nop generated, and in the map
there needs to be an entry, to correspond to the send of +, so that when
machine code pcs are mapped to bytecode pcs there are the correct number of
entries in the map.  In the above case, the VM converts the interpreted
frame to a machine code frame (coincidently) on the 20th iteration and
needs to map the bytecode pc to the correct machine code pc to continue in
machine code.  But because of the missing entry in the map for 1-1, the pc
mapping machinery answered 0, and the VM ended up jumping into the void.

Thanks very much for the bug report!


On Fri, Nov 30, 2012 at 9:07 AM, Jon Anderson jonkander...@gmail.comwrote:

 Hi all,

 I don't post to lists often, but I thought some of you might be
 interested in these few lines of code that crash the CogVM on both
 Linux and Windows.  File-in the Smalltalk code below, then evaluate
 [nil crashCogVM].  The code uses [1-1] but it could use [1+1] or
 [56+98].  I put the code on nil, but that is not important either.  I
 think the important thing is that the primitive (+ or -) is evaluated
 but the result is not assigned into any variable.  Also important is
 that the code is put into a loop that I assume has been JIT optimized.
 The image I used is Pharo 1.4 one-click with latest update #14459.
 This code does not crash StackVM. Have fun! - Jon.

 !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012
 17:26'!
 crashCogVM
  Evaluate [
 nil crashCogVM ]

 | i |
 i := 20.
 1 to: i do: [:d | 1-1 ]
 ! !




-- 
best,
Eliot

Re: [Pharo-project] GSoC: ARM jitter for Squeak VM

[Eliot Miranda]

On Fri, Nov 23, 2012 at 12:56 PM, Carla F. Griggio
carla.grig...@gmail.comwrote:

 Hello!
 I'm copying Lars and Eliot, who worked on this project during the summer,
 so maybe they can update everyone on the state of the project.


It is in progress.  Lars has completed the code generator and is working on
the C calling interface.  There are some changes required to the inline
cache machinery to accomodate the ARM's use of a link register (essentially
the contents of the link register needs to be pushed on and popped from the
stack at the right points so that the rest of the VM sees the same stack
layout as on x86).  So the system isn't ready yet, but it isn't a long way
away either.  Lars is actively working on it when time allows.

HTH
Eliot




 Cheers,
 Carla.


 On Fri, Nov 23, 2012 at 12:04 PM, Frank Shearar 
 frank.shea...@gmail.comwrote:

 On 23 November 2012 10:49, Dan Corneanu c...@savatech.ro wrote:
  Hi,
  I would really like to have a CogVM for ARM. I am a rookie in this
 field but I
  own a raspberry pi and would love to help in any way possible to move
 this
  forward. Testing maybe ?

 The interpreter VM works perfectly on the Raspberry, so you can at
 least get your Smalltalk fix while folks work on Cog.

 frank





-- 
best,
Eliot

Re: [Pharo-project] CachedBlockClosure was gone on purpose?

[Eliot Miranda]

I replaced the implementation with one based on properties.  It's in Squeak
trunk and works fine.  The VisualWorks style clean-block implementation is
more complex but arguably not better, and being based on become: is less
well suited to Squeak.


On Sat, Nov 17, 2012 at 4:07 AM, Marcus Denker marcus.den...@inria.frwrote:


 On Nov 17, 2012, at 9:05 AM, Marcus Denker marcus.den...@inria.fr wrote:

 
  On Nov 17, 2012, at 8:20 AM, Mariano Martinez Peck 
 marianop...@gmail.com wrote:
 
  Because it is not present in 2.0 but I couldn't find any issue about
 that.
 

 Issue was http://code.google.com/p/pharo/issues/detail?id=6708

 --
 Marcus Denker -- http://marcusdenker.de





-- 
best,
Eliot

[Pharo-project] How to force selection update in the debugger?

[Eliot Miranda]

Hi All,

I submitted a run until feature for the debugger to the Squeak inbox
recently and would commit it to trunk except that I'd like the option of
having the selection update on each step.  But I can't see how to do that.
 I *think* selection update is done with a callback here in
Debuggercontents:selection:


Smalltalk isMorphic ifTrue:
[World
addAlarm: #changed:
withArguments: #(contentsSelection)
for: self
at: (Time millisecondClockValue + 200)].

And I'm not sure how this causes the selection to update.  Is it part of
text morph draw or a separate thing?  This is too convoluted to look
through.  So perhaps someone can help e.  If I want the selection to redraw
what's the minimum action necessary.  This is as part of a loop that looks
like

[self selectedContext == context
 and: [(value := receiver with: context executeMethod: method) == false]]
whileTrue:
[self doStep].

i.e. after the doStep I'd like to force the code pane to update its
selection.

AdvThanksance
-- 
best,
Eliot

Re: [Pharo-project] BlockClosureensure: implementation

[Eliot Miranda]

On Mon, Oct 22, 2012 at 2:17 AM, Clément Bera clement.b...@inria.fr wrote:

 Hello,

 I don't understand something on BlockClosureensure:. Why does it use
 'self valueNoContextSwitch'  and not 'self value' ? In which case is there
 an issue ?


Prior to my closure implementation BlockContextvalue[:value:*] was not a
context switch point.  So to preserve the threading semantics of ensure: we
implemented ensure: in terms of BlockClosurevalueNoContextSwitch, which
is not a context-switch point, as opposed to BlockClosurevalue[:value:*].
 The context switch points in the VM are non-primitive sends (or failing
primitives, i.e. full method activation), backward branches, the Process
primitives suspend, resume, signal and wait (and CrtiticalSection/Mutex
enter and exit) and block evaluation.



 Thank you for any answers

 BlockClosureensure: is implemented this way :

 ensure: aBlock
 Evaluate a termination block after evaluating the receiver, regardless of
 whether the receiver's evaluation completes.  N.B.  This method is *not*
 implemented as a primitive.  Primitive 198 always fails.  The VM uses prim
 198 in a context's method as the mark for an ensure:/ifCurtailed:
 activation.

 | complete returnValue |
 primitive: 198
 returnValue := *self valueNoContextSwitch*.
 complete ifNil:[
 complete := true.
 aBlock value.
 ].
 ^ returnValue




-- 
best,
Eliot

Re: [Pharo-project] Yet another Notation format: Object literals

[Eliot Miranda]

HI Dale, Hi Igor,

On Fri, Oct 19, 2012 at 9:33 AM, Dale Henrichs dhenr...@vmware.com wrote:

 Igor,

 you can do anything you like ... you mean like choosing to use STON and
 not invent my own notation format?

 STON is a perfectly good notation format for Smalltalk...

 Methinks that with your recent suggestions are no longer using literal
 Smalltalk syntax which is fine, if we are not restricted to literal
 Smalltalk syntax, then the following should be a valid format:

 {
 category : Topez-Client-Core,
 classinstvars : [
  ],
 classvars : [
  ],
 commentStamp : ,
 instvars : [
 project,
 package,
 currentClass,
 classOrInstance,
 category,
 selector,
 history,
 currentWindowId,
 windows,
 namedWindows ],
 name : TZTopezStatus,
 pools : [
  ],
 super : Object,
 type : normal }

 which brings us back to were we started.


Sorry to come late to the party and sorry to point out the obvious but the
above is fine in Igor's scheme if one gives up double quotes (since these
are comment characters).   So the above, with single quotes replacing the
double quotes, and #(...) replacing {...} is a valid Smalltalk literal.  Is
the latter any the less readable?  I don't think so.  Do you, Dale?  (and
sorry if the conversation has already moved on).


 Smalltalk does not have a literal syntax for dictionaries. While
 fabricating dictionaries from literal arrays is possible, the results are
 not very readable ... unless you start taking liberties with Smalltalk
 syntax...

 If you are no longer restricting yourself to Smalltalk syntax, then what's
 wrong with the STON notation above?

 Dale

 - Original Message -
 | From: Igor Stasenko siguc...@gmail.com
 | To: Pharo-project@lists.gforge.inria.fr
 | Sent: Friday, October 19, 2012 9:10:26 AM
 | Subject: Re: [Pharo-project] Yet another Notation format: Object literals
 |
 | On 19 October 2012 16:55, Dale Henrichs dhenr...@vmware.com wrote:
 |  Igor,
 | 
 |  I'm afraid that your notation is not very friendly to humans ... a
 |  computer can keep track of the key value pairs in the literal
 |  dictionary, but a human will fail very quickly...
 | 
 |  The appeal of JSON (and STON) is that the output is readable by
 |  mere mortals:
 | 
 |(JavaScript Object Notation) is a lightweight
 |data-interchange format. It is easy for humans to
 |read and write.
 | 
 |  What we're missing from Smalltalk is a literal dictionary or
 |  literal map syntax ... without that I'm afraid that for human
 |  friendly, lightweight notations we have to step away from the
 |  Smalltalk syntax - STON does this very nicely BTW...
 |
 | no problem, Dale.
 | What symbol you want to have to separate keys from values?
 | is '-' ok?
 |
 | DictionaryasObjectLiteral
 |
 |   convert a receiver into an object literal 
 |
 |   ^ Array streamContents: [:stream |
 |   stream nextPut: self class name.
 |   self keysAndValuesDo: [:key :value |
 |   stream
 |   nextPut: key asObjectLiteral;
 |   nextPut: #-;
 |   nextPut: value asObjectLiteral ] ]
 |
 | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral
 |
 | #(#Dictionary
 | #a #'-' #b
 | #c #'-' #d)
 |
 | which if you pretty-print will look like:
 |
 | #(
 | Dictionary
 | a - b
 | c - d
 | )
 |
 | is it better?
 | or you prefer this one:
 |
 | #(
 | Dictionary
 | (a - b)
 | (c - d)
 | )
 |
 | you can do anything you like, by implementing the conversion methods
 | in a way you like :)
 |
 | 
 |  Dale
 | 
 |  - Original Message -
 |  | From: Igor Stasenko siguc...@gmail.com
 |  | To: Pharo Development Pharo-project@lists.gforge.inria.fr
 |  | Sent: Friday, October 19, 2012 4:09:22 AM
 |  | Subject: [Pharo-project] Yet another Notation format: Object
 |  | literals
 |  |
 |  | Hi,
 |  | as i promised before, here the simple smalltalk-based literal
 |  | format.
 |  | It based on smalltalk syntax, and so, unlike JSON, it doesn't
 |  | needs
 |  | to
 |  | have separate parser (a normal smalltalk parser used for that).
 |  |
 |  | The idea is quite simple:
 |  | you can tell any object to represent itself as an 'object
 |  | literal' ,
 |  | for example:
 |  |
 |  | (1@3) asObjectLiteral
 |  | --  #(#Point 1 3)
 |  |
 |  | { 1@2.  3@4. true. false . nil  } asObjectLiteral
 |  |
 |  | - #(#Array #(#Point 1 2) #(#Point 3 4) true false nil)
 |  |
 |  | (Dictionary newFromPairs: { 1-#(1 2 3) . 'foo' - 'bar' })
 |  | asObjectLiteral
 |  | -
 |  |  #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar')
 |  |
 |  | Next thing, you can 'pretty-print' it (kinda):
 |  |
 |  | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral
 |  |
 

Re: [Pharo-project] Yet another Notation format: Object literals

[Eliot Miranda]

On Fri, Oct 19, 2012 at 2:42 PM, Dale Henrichs dhenr...@vmware.com wrote:

 Eliot,

 STON (and JSON IIRC) allows either $ or $' as string literal delimiters,
 so I am not holding onto the $ as a key readability component.

 For me:

   { 'category' : 'Topez-Client-Core'}

 is perfectly readable and could be accomplished with the JSON
 reader/writer


agreed, but you're not answering my question.  Is Igor's any the less
readable?



 Dale
 - Original Message -
 | From: Eliot Miranda eliot.mira...@gmail.com
 | To: Pharo-project@lists.gforge.inria.fr
 | Sent: Friday, October 19, 2012 2:07:28 PM
 | Subject: Re: [Pharo-project] Yet another Notation format: Object literals
 |
 | HI Dale, Hi Igor,
 |
 |
 | On Fri, Oct 19, 2012 at 9:33 AM, Dale Henrichs  dhenr...@vmware.com
 |  wrote:
 |
 |
 | Igor,
 |
 | you can do anything you like ... you mean like choosing to use STON
 | and not invent my own notation format?
 |
 | STON is a perfectly good notation format for Smalltalk...
 |
 | Methinks that with your recent suggestions are no longer using
 | literal Smalltalk syntax which is fine, if we are not restricted to
 | literal Smalltalk syntax, then the following should be a valid
 | format:
 |
 | {
 | category : Topez-Client-Core,
 | classinstvars : [
 | ],
 | classvars : [
 | ],
 | commentStamp : ,
 | instvars : [
 | project,
 | package,
 | currentClass,
 | classOrInstance,
 | category,
 | selector,
 | history,
 | currentWindowId,
 | windows,
 | namedWindows ],
 | name : TZTopezStatus,
 | pools : [
 | ],
 | super : Object,
 | type : normal }
 |
 | which brings us back to were we started.
 |
 |
 |
 | Sorry to come late to the party and sorry to point out the obvious
 | but the above is fine in Igor's scheme if one gives up double quotes
 | (since these are comment characters). So the above, with single
 | quotes replacing the double quotes, and #(...) replacing {...} is a
 | valid Smalltalk literal. Is the latter any the less readable? I
 | don't think so. Do you, Dale? (and sorry if the conversation has
 | already moved on).
 |
 |
 |
 |
 | Smalltalk does not have a literal syntax for dictionaries. While
 | fabricating dictionaries from literal arrays is possible, the
 | results are not very readable ... unless you start taking liberties
 | with Smalltalk syntax...
 |
 | If you are no longer restricting yourself to Smalltalk syntax, then
 | what's wrong with the STON notation above?
 |
 |
 | Dale
 |
 | - Original Message -
 | | From: Igor Stasenko  siguc...@gmail.com 
 |
 |
 | | To: Pharo-project@lists.gforge.inria.fr
 | | Sent: Friday, October 19, 2012 9:10:26 AM
 | | Subject: Re: [Pharo-project] Yet another Notation format: Object
 | | literals
 | |
 | | On 19 October 2012 16:55, Dale Henrichs  dhenr...@vmware.com 
 | | wrote:
 | |  Igor,
 | | 
 | |  I'm afraid that your notation is not very friendly to humans ...
 | |  a
 | |  computer can keep track of the key value pairs in the literal
 | |  dictionary, but a human will fail very quickly...
 | | 
 | |  The appeal of JSON (and STON) is that the output is readable by
 | |  mere mortals:
 | | 
 | |  (JavaScript Object Notation) is a lightweight
 | |  data-interchange format. It is easy for humans to
 | |  read and write.
 | | 
 | |  What we're missing from Smalltalk is a literal dictionary or
 | |  literal map syntax ... without that I'm afraid that for human
 | |  friendly, lightweight notations we have to step away from the
 | |  Smalltalk syntax - STON does this very nicely BTW...
 | |
 | | no problem, Dale.
 | | What symbol you want to have to separate keys from values?
 | | is '-' ok?
 | |
 | | DictionaryasObjectLiteral
 | |
 | | convert a receiver into an object literal 
 | |
 | | ^ Array streamContents: [:stream |
 | | stream nextPut: self class name.
 | | self keysAndValuesDo: [:key :value |
 | | stream
 | | nextPut: key asObjectLiteral;
 | | nextPut: #-;
 | | nextPut: value asObjectLiteral ] ]
 | |
 | | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral
 | |
 | | #(#Dictionary
 | | #a #'-' #b
 | | #c #'-' #d)
 | |
 | | which if you pretty-print will look like:
 | |
 | | #(
 | | Dictionary
 | | a - b
 | | c - d
 | | )
 | |
 | | is it better?
 | | or you prefer this one:
 | |
 | | #(
 | | Dictionary
 | | (a - b)
 | | (c - d)
 | | )
 | |
 | | you can do anything you like, by implementing the conversion
 | | methods
 | | in a way you like :)
 | |
 | | 
 | |  Dale
 | | 
 | |  - Original Message -
 | |  | From: Igor Stasenko  siguc...@gmail.com 
 | |  | To: Pharo Development  Pharo-project@lists.gforge.inria.fr 
 | |  | Sent: Friday, October 19, 2012 4:09:22 AM
 | |  | Subject: [Pharo-project] Yet another Notation format: Object
 | |  | literals
 | |  |
 | |  | Hi,
 | |  | as i promised before, here the simple smalltalk-based literal
 | |  | format.
 | |  | It based on smalltalk syntax, and so, unlike JSON, it doesn't
 | |  | needs
 | |  | to
 | |  | have separate parser (a normal smalltalk parser used

Re: [Pharo-project] A trend and an unfair comparison about js everywhere

[Eliot Miranda]

On Tue, Oct 16, 2012 at 12:55 AM, dimitris chloupis theki...@yahoo.co.ukwrote:

 Frankly , I don't find web development that much useful and certainly
 don't believe that web is the future. My money is on the desktop.


I wouldn't put your money on the desktop.  While reports of the desktop's
demise are premature, it's no longer growing.  The desktop is alive and
well but in a niche.   The future (actually the present) is on the smart
phone, or embedded in almost anything.  We may spend or time in front of a
desktop but the world is watching, touching, feeling, listening and
speaking to their phone.

The phone however is a mobile device and hence it needs the internet and
the web is the internet's gui, at least its non-proprietary gui (iTunes,
appStore et al being the proprietary guis).  The iPhone shows that
framework is more important than programming language, and that js isn't
necessarily important for mobile, but it is considered neutral compared to
e.g. flash.



 The very fact that the most popular web app, by far nowdays is facebook
 and the very fact that if you took facebook out today people would lose
 nothing in practicality tells so much about what web is all about. Web is
 not all bad of course, its still without any doubt the library of
 Alexandria but most of it , its just pointless way of killing your free
 time.

 The trend is to push web to the desktop and I think that has been proven a
 very bad idea. Web technology is based on some very bad design decisions
 and it makes me laugh when technologies like node.js take the web world by
 storm when desktop has similar technologies for far too long.

 If you looks carefully you will also see that Desktop is more and more
 pushing to the web, so for me it looks like web development is not going to
 have much of a chance. Many existing programming languages are already
 compiling to js, but even in that case why even bother ? IT makes sense for
 mobile devices , but what will happen if for example pharo and squeak start
 making ports for those mobile devices . Why bother with JS at all ?

 I try to make a visual coding project and I did consider amber and some js
 libraries and to my surprise the only dynamic graphic library I found of
 some serious usefulness was processing.js and its just too slow for what I
 want to achieve. And if you think about all those so called web
 technologies are really sandboxed , limited and slow desktop technologies.

 I still find the fact that a browser can run anywhere extremely tempting
 but in the end I dont think its really worth it. And yes I disagree with
 the video of trying to say that web is like electricity. When electricity
 came out there was nothing like it, with the web its very diffirent because
 not only desktop can do many of the things that web can , all web
 technologies are practically desktop technologies. Also even if you take a
 look at how much Desktop has progressed 10 years and how much the web ,
 even though the web is super hyped those past 10 years you will get a very
 clear picture of how things really are.

 I dont think squeak or pharo should turn their backs to the web
 technologies , js and all others (and I love the fact that projects like
 amber do exist) but I would prefer if more effort is spent on making sure
 that they work on all platforms equally good.

 From where I am standing there is no competitiveness in usefulness when it
 comes to JS and web technology there is just competitiveness in popularity
 and hype. And I would rather prefer if pharo and squeak dont play that game
 and continue being actually useful , innovative , easy to use ,
 technologies. Web is certainly tempting but in the end its an empty
 promise.

   --
 *From:* sebast...@flowingconcept.com sebast...@flowingconcept.com
 *To:* Pharo-project@lists.gforge.inria.fr
 *Sent:* Monday, 15 October 2012, 23:02
 *Subject:* [Pharo-project] A trend and an unfair comparison about js
 everywhere

 Hi guys,

 all comparisons are unfair I know but this is only to make you guy aware
 of this (please ignore if you're already).

 Here is the thing:

 The Jeff Bezos' Electricity Metaphor:
 http://www.ted.com/talks/jeff_bezos_on_the_next_web_innovation.html

 Makes (probably) any smalltalker remember the Alan Kay's talk about having
 in the internet an IP for every object and spectacular computer science
 ideas like that.

 The js everywhere trend makes a lot of sense. Once it achieves critical
 mass it might tempt intel and friends to do some hardware accelerator for
 js VM's. Who knows. We have a long way to go but, in the meantime, all js
 staked frameworks make a lot of sense and WILL get traction because of
 that. Example:

 http://www.wakanda.org/

 A talk here:
 https://vimeo.com/31603156

 So.. the unfair question here would be:

 What we'll have to match that competitiveness?

 sebastian

 o/

 PS: Pharo + WebSockets + Amber sounds in that line doesn't?






-- 
best,
Eliot

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

[Eliot Miranda]

On Sat, Sep 22, 2012 at 11:22 AM, Igor Stasenko siguc...@gmail.com wrote:

 First, we need to make one thing:

 Change the VM to not call ioProcessEvents function directly, but
 rather use a variable which will hold a function pointer.
 Initially, when VM starts, that function pointer is NULL, and so,
 process events is NOP.


Please don't reinvent the wheel.  The Cog source has a variable
inIOProcessEvents that controls this.  If negative it disables
inIOProcessEvents.  If non-negative it prevents reentrancy, essential if
one is receiving events from the OS.  There's a
primitive, primitiveEventProcessingControl, to flip it between the enabled
and disabled states.

This code has been used for years in the Newspeak system which has a full
native GUI on Windows.

Going your own way creates an unnecessary fork.


 Then we need to implement  a module which will manage host windows,
 and once image tells it to create a window,
 it can change the function pointer to ioProcessEvents to own function.

 This change, would allow us to temporary disable any external event
 processing (like in case of callbacks).

 Second, we should move all event-related stuff to new plugin (for
 instance, all definitions in sq.h
 like sqInputEvent , ioSetInputSemaphore() ioGetNextEvent() etc).

 For all UI-related stuff the image should communicate with a new
 plugin, while VM should get rid of all knowledge of any existence of
 UI events,
 like input semaphores, primitives for fetching them etc.

 Third, of course, all screen update/refresh primitives should be
 deprecated, and image should use new primitives to update the contents
 of host window(s).


 --
 Best regards,
 Igor Stasenko.




-- 
best,
Eliot

Re: [Pharo-project] [Vm-dev] [NB] NativeBoost meets JIT

[Eliot Miranda]

Hi Igor,

great news!

On Fri, Sep 21, 2012 at 7:59 AM, Igor Stasenko siguc...@gmail.com wrote:


 Hello there,

 so, we're entered a new area, where native code, generated from image
 side can be run directly by JIT.
 This feature was one of the first things which i wanted to try, once
 Eliot released Cog :)

 The way how we do that, is when VM decides to JIT a specific method,
 we copying the native code (from method trailer)
 directly into the method's code.
 All you need to do is to use special primitive for that 220 (
 #primitiveVoltage)

 So, a first question, which we wanted to be answered is how faster to
 run native code by JIT,
 comparing to running native code via NativeBoost primitive , which is
 #primitiveNativeCall..

 For here are methods, which just answer 42:

 This one using #primitiveNativeCall

 nbFoo2
 primitive: #primitiveNativeCall module: #NativeBoostPlugin error:
 errorCode

 ^ NBNativeCodeGen methodAssembly: [:gen :proxy :asm |
 asm noStackFrame.
 asm
 mov: (42  1) + 1 to: asm EAX;
 ret.
 ]

 And this one uses JIT:

 nbFoo
 primitive: 220 error: errorCode

 [ errorCode = ErrRunningViaInterpreter  ] whileTrue: [ ^ self
 nbFoo ].

 ^ NBNativeCodeGen jitMethodAssembly: [:gen :proxy :asm |
 asm noStackFrame.
 asm
 mov: (42  1) + 1 to: asm EDX;
 ret: 4 asUImm.
 ]

 And this one is code which JIT can do:

 nbFoo42
 ^ 42

 So, here the numbers:

 Time to run via #primitiveNativeCall :

 [1 timesRepeat: [ MyClass nbFoo2  ] ] timeToRun
  6995

 Time to run via JIT:

 [1 timesRepeat: [ MyClass nbFoo  ] ] timeToRun
 897

 Time to run JITed method:

 [1 timesRepeat: [ MyClass nbFoo42  ] ] timeToRun
 899

 so, as you can see, the JITed method and our custom generated code is
 on par (which is logical ;).

 Time to run an empty loop:

 [1 timesRepeat: [  ] ] timeToRun 679


 So, here the result, if we extract the loop overhead, we can see the
 difference in
 calling our native code when it uses JIT vs using #primitiveNativeCall :

 (6995 - 679 ) / (897- 679) asFloat 28.972477064220183

 28 times faster

 So, with this new feature, we now can make our generated code to run
 with unmatched speed,
 without overhead related to #primitiveNativeCall.
 This is especially useful for implementing primives which involving
 heavy numeric crunching.

 I would release this code to public, but there's one little
 discrepancy i need to deal with first:

 (one little problem, which i hope Eliot can help to solve)

  it looks like primitivePerform: never enters the JIT mode, but always
 executing the method via interpreter.


I'll take a look.  This is all very detailed so I'll need a little time.

This is why you see this code:
 [ errorCode = ErrRunningViaInterpreter  ] whileTrue: [ ^ self
 nbFoo ].

 because if i do it inside of NBNativeCodeGenjitMethodAssembly:,
 which checks for same error and retries the send using perform
 primitive, it never enters the JIT mode,
 resulting in endless loop :(

 This is despite the fact that method is JITed, because we enforce the
 JITing of that method during error handling:

 lastError = ErrRunningViaInterpreter ifTrue: [
 a method contains native code, but executed by
 interpreter 
 method forceJIT ifFalse: [ self error: 'Failed to JIT the
 compiled
 method. Try reducing it''s size ' ].
 ^ self retrySend: aContext
 ].

 The #forceJit is the primitive which i implemented like following:

 primitiveForceJIT

 export: true 

 | val result |

 val := self stackTop.

 (self isIntegerObject: val) ifTrue: [ ^ self primitiveFail ].
 (self isCompiledMethod: val) ifFalse: [ ^ self primitiveFail ].

 (self methodHasCogMethod: val) ifFalse: [
 cogit cog: val selector: objectMemory nilObject ].

 result := (self methodHasCogMethod: val ) ifTrue: [ objectMemory
 trueObject ] ifFalse: [ objectMemory falseObject ].

 ^ self pop: 1 thenPush: result.

 As you can see from its usage, if VM, for some reason will fail to jit
 the method, the primitive will answer false,
 and we will stop with an error.. Which apparently never happens.
 Still, a #primitivePerform seems like ignoring that the method
 contains machine code an always runs it interpreted :(

 I do not like the idea, that users will be forced to manually put such
 loops in every method they will write..
 any ideas/suggestions how to overcome that?


Yes.  The JIT should be told that methods that have NB code should be
jitted.  But right now I don't understand enough of how NB code is
generated and methods marked that they have NB code etc to know exactly how
to do this.  I need to play around a bit.



-- 
best,

Re: [Pharo-project] how to start a cog vm on debian 6.0.4

[Eliot Miranda]

On Thu, Sep 13, 2012 at 11:08 PM, Tudor Girba tu...@tudorgirba.com wrote:

 Hi,

 Thanks for the reply and suggestion. I slept over it and when I woke
 up I realized that maybe something went wrong with installing
 ia32-libs. I reinstalled them and now things look fine. I get:
 lib/squeak/4.0-2585# ldd squeak
 libutil.so.1 = /lib32/libutil.so.1 (0xb7efe000)
 libdl.so.2 = /lib32/libdl.so.2 (0xb7efa000)
 libpthread.so.0 = /lib32/libpthread.so.0 (0xb7ee)
 libm.so.6 = /lib32/libm.so.6 (0xb7eba000)
 libnsl.so.1 = /lib32/libnsl.so.1 (0xb7ea3000)
 libc.so.6 = /lib32/libc.so.6 (0xb7d5c000)
 /lib/ld-linux.so.2 (0xb7f0d000)

 Cheers,
 Doru


Cool.  I think the script could be rewritten so that if SVMLLP can't be
determined and the system is 64-bit it makes a suggestion to check that the
32-bit libraries are correctly installed.  I wonder is there a way of
checking that they are correctly installed.  One obvious thing to do is to
match the case where ldd doesn't produce any output.


 On Thu, Sep 13, 2012 at 11:35 PM, Eliot Miranda eliot.mira...@gmail.com
 wrote:
 
 
  On Thu, Sep 13, 2012 at 12:24 PM, Tudor Girba tu...@tudorgirba.com
 wrote:
 
  Hi,
 
  Thanks for the suggestion. I do not know exactly what it means, but I
  tried and the output does not look like yours (see below). Any idea
  what not a dynamic executable means?
 
 
  it means its not recognized by your OS as a valid executable file.  So
  you're out of luck.  (Forget my private email).  So this OS can't run
 32-bit
  executables built on other linuxes.  If you compile hello world with -m32
  what does file answer?  e.g.
 
  McStalker.oscogvm$ cat hw.c END
  int main() { printf(hello world\n); return 0; }
  END
  McStalker.oscogvm$ cc -o hw -m32 hw.c
  hw.c: In function 'main':
  hw.c:1: warning: incompatible implicit declaration of built-in function
  'printf'
  McStalker.oscogvm$ ./hw
  hello world
  McStalker.oscogvm$ file hw
  hw: Mach-O executable i386
  McStalker.oscogvm$
 
  and what does file answer for squeak?
 
 
  lib/squeak/4.0-2585# ls
  B3DAcceleratorPlugin  SqueakFFIPrims   squeak
  vm-display-null
  vm-sound-null
  BochsIA32Plugin   UUIDPlugin   vm-display-X11
  vm-sound-ALSA
  LocalePlugin  UnixOSProcessPlugin  vm-display-fbdev
  vm-sound-OSS
 
  lib/squeak/4.0-2585# ldd squeak
  not a dynamic executable
 
  lib/squeak/4.0-2585# ldd vm-display-X11
  not a dynamic executable
 
  lib/squeak/4.0-2585# ls -al
  total 9468
  drwxr-xr-x 2 root root4096 Sep 12 21:51 .
  drwxr-xr-x 3 root root4096 Sep 12 21:51 ..
  -rwxr-xr-x 1 root root  144996 Sep 12 21:51 B3DAcceleratorPlugin
  -rwxr-xr-x 1 root root 5376041 Sep 12 21:51 BochsIA32Plugin
  -rwxr-xr-x 1 root root   31714 Sep 12 21:51 LocalePlugin
  -rwxr-xr-x 1 root root   77720 Sep 12 21:51 SqueakFFIPrims
  -rwxr-xr-x 1 root root   19617 Sep 12 21:51 UUIDPlugin
  -rwxr-xr-x 1 root root   90561 Sep 12 21:51 UnixOSProcessPlugin
  -rwxr-xr-x 1 root root 3408704 Sep 12 21:51 squeak
  -rwxr-xr-x 1 root root  235076 Sep 12 21:51 vm-display-X11
  -rwxr-xr-x 1 root root   94225 Sep 12 21:51 vm-display-fbdev
  -rwxr-xr-x 1 root root   27549 Sep 12 21:51 vm-display-null
  -rwxr-xr-x 1 root root   42045 Sep 12 21:51 vm-sound-ALSA
  -rwxr-xr-x 1 root root   56587 Sep 12 21:51 vm-sound-OSS
  -rwxr-xr-x 1 root root   13377 Sep 12 21:51 vm-sound-null
 
  Cheers,
  Doru
 
 
  On Thu, Sep 13, 2012 at 9:14 PM, Bernardo Ezequiel Contreras
  vonbecm...@gmail.com wrote:
   for instance, on ubuntu maverick and with eliot's vm
  
   ~/bin/pharo-vm/cog/r2502/lib/squeak/4.0-2502$ ls
   B3DAcceleratorPlugin  squeak UnixOSProcessPlugin
   vm-display-X11
   LocalePlugin  SqueakFFIPrims UUIDPlugin
   vm-sound-ALSA
   PharoV10.sources  SqueakV41.sources  vm-display-null
   vm-sound-null
   ~/bin/pharo-vm/cog/r2502/lib/squeak/4.0-2502$ ldd squeak
   linux-gate.so.1 =  (0x00396000)
   libutil.so.1 = /lib/libutil.so.1 (0x00655000)
   libdl.so.2 = /lib/libdl.so.2 (0x00987000)
   libpthread.so.0 = /lib/libpthread.so.0 (0x00373000)
   libm.so.6 = /lib/libm.so.6 (0x00e07000)
   libnsl.so.1 = /lib/libnsl.so.1 (0x00d73000)
   libc.so.6 = /lib/libc.so.6 (0x00e2f000)
   /lib/ld-linux.so.2 (0x0084a000)
   or
   $ ldd vm-display-X11
   linux-gate.so.1 =  (0x008e2000)
   libGL.so.1 = /usr/lib/mesa/libGL.so.1 (0x00901000)
   libXext.so.6 = /usr/lib/libXext.so.6 (0x00537000)
   libSM.so.6 = /usr/lib/libSM.so.6 (0x00518000)
   libICE.so.6 = /usr/lib/libICE.so.6 (0x007ec000)
   libdl.so.2 = /lib/libdl.so.2 (0x0075e000)
   libpthread.so.0 = /lib/libpthread.so.0 (0x0011)
   libm.so.6 = /lib/libm.so.6 (0x0012a000)
   libnsl.so.1 = /lib/libnsl.so.1 (0x00c9)
   libX11.so.6 = /usr/lib/libX11.so.6 (0x005cd000)
   libc.so.6 = /lib/libc.so.6 (0x0015

Re: [Pharo-project] how to start a cog vm on debian 6.0.4

[Eliot Miranda]

I updated the script.  See below.

On Fri, Sep 14, 2012 at 10:26 AM, Eliot Miranda eliot.mira...@gmail.comwrote:



 On Thu, Sep 13, 2012 at 11:08 PM, Tudor Girba tu...@tudorgirba.comwrote:

 Hi,

 Thanks for the reply and suggestion. I slept over it and when I woke
 up I realized that maybe something went wrong with installing
 ia32-libs. I reinstalled them and now things look fine. I get:
 lib/squeak/4.0-2585# ldd squeak
 libutil.so.1 = /lib32/libutil.so.1 (0xb7efe000)
 libdl.so.2 = /lib32/libdl.so.2 (0xb7efa000)
 libpthread.so.0 = /lib32/libpthread.so.0 (0xb7ee)
 libm.so.6 = /lib32/libm.so.6 (0xb7eba000)
 libnsl.so.1 = /lib32/libnsl.so.1 (0xb7ea3000)
 libc.so.6 = /lib32/libc.so.6 (0xb7d5c000)
 /lib/ld-linux.so.2 (0xb7f0d000)

 Cheers,
 Doru


 Cool.  I think the script could be rewritten so that if SVMLLP can't be
 determined and the system is 64-bit it makes a suggestion to check that the
 32-bit libraries are correctly installed.  I wonder is there a way of
 checking that they are correctly installed.  One obvious thing to do is to
 match the case where ldd doesn't produce any output.


Author: eliot
Date: 2012-09-14 10:40:40 -0700 (Fri, 14 Sep 2012)
New Revision: 2604

Modified:
   branches/Cog/platforms/unix/config/bin.squeak.sh.in
   branches/Cog/platforms/unix/config/squeak.sh.in
Log:
On unix have the start-up script produce an hopefully helpful error message
when ldd doesn't run on 64-bit installations.


Modified: branches/Cog/platforms/unix/config/bin.squeak.sh.in
===
--- branches/Cog/platforms/unix/config/bin.squeak.sh.in 2012-09-13 20:00:16
UTC (rev 2603)
+++ branches/Cog/platforms/unix/config/bin.squeak.sh.in 2012-09-14 17:40:40
UTC (rev 2604)
@@ -25,7 +25,12 @@
SVMLLP=/lib/tls/i686/cmov:/lib:/usr/lib/tls/i686/cmov:/usr/lib;;
 /lib/tls/i686/nosegneg/libc*)  \

SVMLLP=/lib/i686/nosegneg/tls:/lib:/usr/lib/i686/nosegneg/tls:/usr/lib;;
-*) echo can't infer base LD_LIBRARY_PATH. Aborting. 12;
+)case `/bin/uname -m || /usr/bin/uname -m` in
+   *64*)   echo /usr/bin/ldd didn't produce any output and the system
is 64 bit.  You may need to (re)install the 32-bit libraries. 12;;
+   *)  echo /usr/bin/ldd didn't produce any output. Can't infer
base LD_LIBRARY_PATH. Aborting. 12
+   esac
+   exit 1;;
+*) echo Can't infer base LD_LIBRARY_PATH. Aborting. 12
exit 1
 esac



 On Thu, Sep 13, 2012 at 11:35 PM, Eliot Miranda eliot.mira...@gmail.com
 wrote:
 
 
  On Thu, Sep 13, 2012 at 12:24 PM, Tudor Girba tu...@tudorgirba.com
 wrote:
 
  Hi,
 
  Thanks for the suggestion. I do not know exactly what it means, but I
  tried and the output does not look like yours (see below). Any idea
  what not a dynamic executable means?
 
 
  it means its not recognized by your OS as a valid executable file.  So
  you're out of luck.  (Forget my private email).  So this OS can't run
 32-bit
  executables built on other linuxes.  If you compile hello world with
 -m32
  what does file answer?  e.g.
 
  McStalker.oscogvm$ cat hw.c END
  int main() { printf(hello world\n); return 0; }
  END
  McStalker.oscogvm$ cc -o hw -m32 hw.c
  hw.c: In function 'main':
  hw.c:1: warning: incompatible implicit declaration of built-in function
  'printf'
  McStalker.oscogvm$ ./hw
  hello world
  McStalker.oscogvm$ file hw
  hw: Mach-O executable i386
  McStalker.oscogvm$
 
  and what does file answer for squeak?
 
 
  lib/squeak/4.0-2585# ls
  B3DAcceleratorPlugin  SqueakFFIPrims   squeak
  vm-display-null
  vm-sound-null
  BochsIA32Plugin   UUIDPlugin   vm-display-X11
  vm-sound-ALSA
  LocalePlugin  UnixOSProcessPlugin  vm-display-fbdev
  vm-sound-OSS
 
  lib/squeak/4.0-2585# ldd squeak
  not a dynamic executable
 
  lib/squeak/4.0-2585# ldd vm-display-X11
  not a dynamic executable
 
  lib/squeak/4.0-2585# ls -al
  total 9468
  drwxr-xr-x 2 root root4096 Sep 12 21:51 .
  drwxr-xr-x 3 root root4096 Sep 12 21:51 ..
  -rwxr-xr-x 1 root root  144996 Sep 12 21:51 B3DAcceleratorPlugin
  -rwxr-xr-x 1 root root 5376041 Sep 12 21:51 BochsIA32Plugin
  -rwxr-xr-x 1 root root   31714 Sep 12 21:51 LocalePlugin
  -rwxr-xr-x 1 root root   77720 Sep 12 21:51 SqueakFFIPrims
  -rwxr-xr-x 1 root root   19617 Sep 12 21:51 UUIDPlugin
  -rwxr-xr-x 1 root root   90561 Sep 12 21:51 UnixOSProcessPlugin
  -rwxr-xr-x 1 root root 3408704 Sep 12 21:51 squeak
  -rwxr-xr-x 1 root root  235076 Sep 12 21:51 vm-display-X11
  -rwxr-xr-x 1 root root   94225 Sep 12 21:51 vm-display-fbdev
  -rwxr-xr-x 1 root root   27549 Sep 12 21:51 vm-display-null
  -rwxr-xr-x 1 root root   42045 Sep 12 21:51 vm-sound-ALSA
  -rwxr-xr-x 1 root root   56587 Sep 12 21:51 vm-sound-OSS
  -rwxr-xr-x 1 root root   13377 Sep 12 21:51 vm-sound-null
 
  Cheers,
  Doru
 
 
  On Thu, Sep 13, 2012 at 9:14 PM, Bernardo Ezequiel Contreras
  vonbecm...@gmail.com wrote:
   for instance

Re: [Pharo-project] how to start a cog vm on debian 6.0.4

[Eliot Miranda]

On Thu, Sep 13, 2012 at 11:53 AM, Tudor Girba tu...@tudorgirba.com wrote:

 Hi,

 I would need to start a Pharo/Pier image on Debian 6.0.4 from the
 command line using Cog. I tried to use both the Cog-VM (from Pharo)
 and the Cog (from Eliot), but none work:

 - If I run the Cog from Eliot returns
 can't infer base LD_LIBRARY_PATH. Aborting.


look at the part of the script that determines LD_LIBRARY_PATH and extend
it suitably.  then let me know how you augmented it.  this is the case that
works out which directories to include, where SVMLLP stands for squeak vm
ld library path.:


# On some linuxes there multiple versions of the C library.  If the image
uses# libc (e.g. through the FFI) then it must use the same version that
the VM uses
# and so it should take precedence over /lib libc.  This is done by setting
# LD_LIBRARY_PATH appropriately, based on ldd's idea of the libc use by the
VM.
case `/usr/bin/ldd $BIN/squeak | /bin/fgrep /libc. | sed 's/^.*= //'` in
/lib/libc*) SVMLLP=/lib:/usr/lib;;
/lib32/libc*) SVMLLP=/lib32:/usr/lib32;;
/lib64/libc*) SVMLLP=/lib64:/usr/lib64;;
/lib/tls/libc*) SVMLLP=/lib/tls:/lib:/usr/lib/tls:/usr/lib;;
/lib/i386-linux-gnu/libc*) \
SVMLLP=/lib/i386-linux-gnu:/usr/lib/i386-linux-gnu;;
/lib/tls/i686/cmov/libc*) \
SVMLLP=/lib/tls/i686/cmov:/lib:/usr/lib/tls/i686/cmov:/usr/lib;;
/lib/tls/i686/nosegneg/libc*) \
SVMLLP=/lib/i686/nosegneg/tls:/lib:/usr/lib/i686/nosegneg/tls:/usr/lib;;
*) echo can't infer base LD_LIBRARY_PATH. Aborting. 12;
exit 1
esac



 - I could not even get the Pharo Cog to run. Even if the rights for
 the VM are correct, it still says:
 -bash: ./CogVM: No such file or directory

 Any hints as to how to proceed?

 Cheers,
 Doru

 --
 www.tudorgirba.com

 Every thing has its own flow




-- 
best,
Eliot

Re: [Pharo-project] how to start a cog vm on debian 6.0.4

[Eliot Miranda]

On Thu, Sep 13, 2012 at 12:24 PM, Tudor Girba tu...@tudorgirba.com wrote:

 Hi,

 Thanks for the suggestion. I do not know exactly what it means, but I
 tried and the output does not look like yours (see below). Any idea
 what not a dynamic executable means?


it means its not recognized by your OS as a valid executable file.  So
you're out of luck.  (Forget my private email).  So this OS can't run
32-bit executables built on other linuxes.  If you compile hello world with
-m32 what does file answer?  e.g.

McStalker.oscogvm$ cat hw.c END
 int main() { printf(hello world\n); return 0; }
 END
McStalker.oscogvm$ cc -o hw -m32 hw.c
hw.c: In function 'main':
hw.c:1: warning: incompatible implicit declaration of built-in function
'printf'
McStalker.oscogvm$ ./hw
hello world
McStalker.oscogvm$ file hw
hw: Mach-O executable i386
McStalker.oscogvm$

and what does file answer for squeak?


 lib/squeak/4.0-2585# ls
 B3DAcceleratorPlugin  SqueakFFIPrims   squeak
  vm-display-null
 vm-sound-null
 BochsIA32Plugin   UUIDPlugin   vm-display-X11vm-sound-ALSA
 LocalePlugin  UnixOSProcessPlugin  vm-display-fbdev  vm-sound-OSS

 lib/squeak/4.0-2585# ldd squeak
 not a dynamic executable

 lib/squeak/4.0-2585# ldd vm-display-X11
 not a dynamic executable

 lib/squeak/4.0-2585# ls -al
 total 9468
 drwxr-xr-x 2 root root4096 Sep 12 21:51 .
 drwxr-xr-x 3 root root4096 Sep 12 21:51 ..
 -rwxr-xr-x 1 root root  144996 Sep 12 21:51 B3DAcceleratorPlugin
 -rwxr-xr-x 1 root root 5376041 Sep 12 21:51 BochsIA32Plugin
 -rwxr-xr-x 1 root root   31714 Sep 12 21:51 LocalePlugin
 -rwxr-xr-x 1 root root   77720 Sep 12 21:51 SqueakFFIPrims
 -rwxr-xr-x 1 root root   19617 Sep 12 21:51 UUIDPlugin
 -rwxr-xr-x 1 root root   90561 Sep 12 21:51 UnixOSProcessPlugin
 -rwxr-xr-x 1 root root 3408704 Sep 12 21:51 squeak
 -rwxr-xr-x 1 root root  235076 Sep 12 21:51 vm-display-X11
 -rwxr-xr-x 1 root root   94225 Sep 12 21:51 vm-display-fbdev
 -rwxr-xr-x 1 root root   27549 Sep 12 21:51 vm-display-null
 -rwxr-xr-x 1 root root   42045 Sep 12 21:51 vm-sound-ALSA
 -rwxr-xr-x 1 root root   56587 Sep 12 21:51 vm-sound-OSS
 -rwxr-xr-x 1 root root   13377 Sep 12 21:51 vm-sound-null

 Cheers,
 Doru


 On Thu, Sep 13, 2012 at 9:14 PM, Bernardo Ezequiel Contreras
 vonbecm...@gmail.com wrote:
  for instance, on ubuntu maverick and with eliot's vm
 
  ~/bin/pharo-vm/cog/r2502/lib/squeak/4.0-2502$ ls
  B3DAcceleratorPlugin  squeak UnixOSProcessPlugin
  vm-display-X11
  LocalePlugin  SqueakFFIPrims UUIDPlugin
 vm-sound-ALSA
  PharoV10.sources  SqueakV41.sources  vm-display-null
  vm-sound-null
  ~/bin/pharo-vm/cog/r2502/lib/squeak/4.0-2502$ ldd squeak
  linux-gate.so.1 =  (0x00396000)
  libutil.so.1 = /lib/libutil.so.1 (0x00655000)
  libdl.so.2 = /lib/libdl.so.2 (0x00987000)
  libpthread.so.0 = /lib/libpthread.so.0 (0x00373000)
  libm.so.6 = /lib/libm.so.6 (0x00e07000)
  libnsl.so.1 = /lib/libnsl.so.1 (0x00d73000)
  libc.so.6 = /lib/libc.so.6 (0x00e2f000)
  /lib/ld-linux.so.2 (0x0084a000)
  or
  $ ldd vm-display-X11
  linux-gate.so.1 =  (0x008e2000)
  libGL.so.1 = /usr/lib/mesa/libGL.so.1 (0x00901000)
  libXext.so.6 = /usr/lib/libXext.so.6 (0x00537000)
  libSM.so.6 = /usr/lib/libSM.so.6 (0x00518000)
  libICE.so.6 = /usr/lib/libICE.so.6 (0x007ec000)
  libdl.so.2 = /lib/libdl.so.2 (0x0075e000)
  libpthread.so.0 = /lib/libpthread.so.0 (0x0011)
  libm.so.6 = /lib/libm.so.6 (0x0012a000)
  libnsl.so.1 = /lib/libnsl.so.1 (0x00c9)
  libX11.so.6 = /usr/lib/libX11.so.6 (0x005cd000)
  libc.so.6 = /lib/libc.so.6 (0x0015)
  libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0x002ad000)
  libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x00c0e000)
  libXxf86vm.so.1 = /usr/lib/libXxf86vm.so.1 (0x002b1000)
  libdrm.so.2 = /lib/libdrm.so.2 (0x00d6e000)
  libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x0036d000)
  libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x002b7000)
  libuuid.so.1 = /lib/libuuid.so.1 (0x00719000)
  /lib/ld-linux.so.2 (0x0034f000)
  libxcb.so.1 = /usr/lib/libxcb.so.1 (0x002d3000)
  librt.so.1 = /lib/librt.so.1 (0x002ed000)
  libXau.so.6 = /usr/lib/libXau.so.6 (0x002f6000)
  libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x002fa000)
 
 
 
  cheers
 
  On Thu, Sep 13, 2012 at 4:05 PM, Bernardo Ezequiel Contreras
  vonbecm...@gmail.com wrote:
 
  Tudor,
do a ldd on the binary, and see if you have installed all the required
  libraries for the system
  http://linux.die.net/man/1/ldd
 
  At home, i'm using debian squeeze and it works.
 
  cheers
 
 
  On Thu, Sep 13, 2012 at 3:53 PM, Tudor Girba tu...@tudorgirba.com
 wrote:
 
  Hi,
 
  I would need to start a Pharo/Pier image on Debian 6.0.4 from the
  command line using Cog. I tried to use both the Cog-VM (from Pharo)
 

Re: [Pharo-project] how to start a cog vm on debian 6.0.4

[Eliot Miranda]

On Thu, Sep 13, 2012 at 2:35 PM, Eliot Miranda eliot.mira...@gmail.comwrote:



 On Thu, Sep 13, 2012 at 12:24 PM, Tudor Girba tu...@tudorgirba.comwrote:

 Hi,

 Thanks for the suggestion. I do not know exactly what it means, but I
 tried and the output does not look like yours (see below). Any idea
 what not a dynamic executable means?


 it means its not recognized by your OS as a valid executable file.  So
 you're out of luck.  (Forget my private email).  So this OS can't run
 32-bit executables built on other linuxes.  If you compile hello world with
 -m32 what does file answer?  e.g.

 McStalker.oscogvm$ cat hw.c END
  int main() { printf(hello world\n); return 0; }
  END
 McStalker.oscogvm$ cc -o hw -m32 hw.c
 hw.c: In function 'main':
 hw.c:1: warning: incompatible implicit declaration of built-in function
 'printf'
 McStalker.oscogvm$ ./hw
 hello world
 McStalker.oscogvm$ file hw
 hw: Mach-O executable i386
 McStalker.oscogvm$

 and what does file answer for squeak?


also is there any other place ldd lies, e.g. /usr/bin32/ldd?  i.e. is there
possibly a 32-bit subsystem in a parallel directory hierarchy?



 lib/squeak/4.0-2585# ls
 B3DAcceleratorPlugin  SqueakFFIPrims   squeak
  vm-display-null
 vm-sound-null
 BochsIA32Plugin   UUIDPlugin   vm-display-X11vm-sound-ALSA
 LocalePlugin  UnixOSProcessPlugin  vm-display-fbdev  vm-sound-OSS

 lib/squeak/4.0-2585# ldd squeak
 not a dynamic executable

 lib/squeak/4.0-2585# ldd vm-display-X11
 not a dynamic executable

 lib/squeak/4.0-2585# ls -al
 total 9468
 drwxr-xr-x 2 root root4096 Sep 12 21:51 .
 drwxr-xr-x 3 root root4096 Sep 12 21:51 ..
 -rwxr-xr-x 1 root root  144996 Sep 12 21:51 B3DAcceleratorPlugin
 -rwxr-xr-x 1 root root 5376041 Sep 12 21:51 BochsIA32Plugin
 -rwxr-xr-x 1 root root   31714 Sep 12 21:51 LocalePlugin
 -rwxr-xr-x 1 root root   77720 Sep 12 21:51 SqueakFFIPrims
 -rwxr-xr-x 1 root root   19617 Sep 12 21:51 UUIDPlugin
 -rwxr-xr-x 1 root root   90561 Sep 12 21:51 UnixOSProcessPlugin
 -rwxr-xr-x 1 root root 3408704 Sep 12 21:51 squeak
 -rwxr-xr-x 1 root root  235076 Sep 12 21:51 vm-display-X11
 -rwxr-xr-x 1 root root   94225 Sep 12 21:51 vm-display-fbdev
 -rwxr-xr-x 1 root root   27549 Sep 12 21:51 vm-display-null
 -rwxr-xr-x 1 root root   42045 Sep 12 21:51 vm-sound-ALSA
 -rwxr-xr-x 1 root root   56587 Sep 12 21:51 vm-sound-OSS
 -rwxr-xr-x 1 root root   13377 Sep 12 21:51 vm-sound-null

 Cheers,
 Doru


 On Thu, Sep 13, 2012 at 9:14 PM, Bernardo Ezequiel Contreras
 vonbecm...@gmail.com wrote:
  for instance, on ubuntu maverick and with eliot's vm
 
  ~/bin/pharo-vm/cog/r2502/lib/squeak/4.0-2502$ ls
  B3DAcceleratorPlugin  squeak UnixOSProcessPlugin
  vm-display-X11
  LocalePlugin  SqueakFFIPrims UUIDPlugin
 vm-sound-ALSA
  PharoV10.sources  SqueakV41.sources  vm-display-null
  vm-sound-null
  ~/bin/pharo-vm/cog/r2502/lib/squeak/4.0-2502$ ldd squeak
  linux-gate.so.1 =  (0x00396000)
  libutil.so.1 = /lib/libutil.so.1 (0x00655000)
  libdl.so.2 = /lib/libdl.so.2 (0x00987000)
  libpthread.so.0 = /lib/libpthread.so.0 (0x00373000)
  libm.so.6 = /lib/libm.so.6 (0x00e07000)
  libnsl.so.1 = /lib/libnsl.so.1 (0x00d73000)
  libc.so.6 = /lib/libc.so.6 (0x00e2f000)
  /lib/ld-linux.so.2 (0x0084a000)
  or
  $ ldd vm-display-X11
  linux-gate.so.1 =  (0x008e2000)
  libGL.so.1 = /usr/lib/mesa/libGL.so.1 (0x00901000)
  libXext.so.6 = /usr/lib/libXext.so.6 (0x00537000)
  libSM.so.6 = /usr/lib/libSM.so.6 (0x00518000)
  libICE.so.6 = /usr/lib/libICE.so.6 (0x007ec000)
  libdl.so.2 = /lib/libdl.so.2 (0x0075e000)
  libpthread.so.0 = /lib/libpthread.so.0 (0x0011)
  libm.so.6 = /lib/libm.so.6 (0x0012a000)
  libnsl.so.1 = /lib/libnsl.so.1 (0x00c9)
  libX11.so.6 = /usr/lib/libX11.so.6 (0x005cd000)
  libc.so.6 = /lib/libc.so.6 (0x0015)
  libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0x002ad000)
  libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x00c0e000)
  libXxf86vm.so.1 = /usr/lib/libXxf86vm.so.1 (0x002b1000)
  libdrm.so.2 = /lib/libdrm.so.2 (0x00d6e000)
  libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x0036d000)
  libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x002b7000)
  libuuid.so.1 = /lib/libuuid.so.1 (0x00719000)
  /lib/ld-linux.so.2 (0x0034f000)
  libxcb.so.1 = /usr/lib/libxcb.so.1 (0x002d3000)
  librt.so.1 = /lib/librt.so.1 (0x002ed000)
  libXau.so.6 = /usr/lib/libXau.so.6 (0x002f6000)
  libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x002fa000)
 
 
 
  cheers
 
  On Thu, Sep 13, 2012 at 4:05 PM, Bernardo Ezequiel Contreras
  vonbecm...@gmail.com wrote:
 
  Tudor,
do a ldd on the binary, and see if you have installed all the
 required
  libraries for the system
  http://linux.die.net/man/1/ldd
 
  At home, i'm using debian squeeze and it works

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

[Eliot Miranda]

On Mon, Aug 27, 2012 at 8:44 AM, Ben Coman b...@openinworld.com wrote:






 Igor Stasenko wrote:

 you can open .changes file in another image to rescue your code.


 Thanks Igor.  I gave that a go but couldn't work it out.  I tried the
 following:  Unzipped a fresh image, copied the .changes file into the
 folder to overwrite the existing .changes file, then after starting the
 image tried (World  Tools  Recover lost changes...)  but I get
 Information: this image has never been saved since changes were
 compressed.  Saving the image seems to empty the .changes file.  I could
 not find another way.  Is there something else I should be doing?


Ben, your changes were in the .changes file that you overwrote.  You should
have either
a) unpacked the second image/changes in a different directory
b) renamed the changes file you wanted to recover before unpacking the
second image/changes
c) unpacked the second image/changes with different names
d) anything else that avoids overwriting the changes file you wanted to
recover.

its gone now unless you have a recent backup

 also you can patch the image's bytecode to avoid entering an offending
 method
 (like a method which enters the drawing , just see its bytecode in
 another image,
 and the find same byte sequence in crashing image, and put return self
 bytecode)


 Thanks, but that is beyond my capability at the moment.  Probably wishing
 for too much, but ideally some mechanism might use info from the debug.log
 to do this automatically.

 On 25 August 2012 03:42, Ben Coman b...@openinworld.com wrote:


 Igor Stasenko wrote:


 On 4 August 2012 04:11, Ben Coman b...@openinworld.com wrote:



 As probably many newbies do from time to time, I am learning the system
 splattering 'self halt' around, and once again slipped one into the
 wrong
 place where I should have used 'haltOnce' and had a massive number of
 pre-debugger windows come up.  I managed to get it back this time with
 the
 user interrupt - but not always - and anyhow clearing so many debug
 windows
 is a pain.  So. could 'self halt' be made to monitor the rate that
 the
 halt windows appear, and when more than some value from one of them
 (say
 five per second) it starts getting ignored and shows a dialog asking
 the
 user if they really meant this and enable danger mode, or if they
 screwed
 up
 and want to revert the method containing the suspect 'halt'.




 If we look from user's perspective (not machine perspective), apparently
 it is pointless to throw so many messages at the user's face, because
 he cannot deal with them
 in meaningful manner at such rate.
 So, i think there should be something like following:
 - if exception requires a user interaction, we do show the popup, but
 meanwhile remember
 the exception which initiated it.
 - if there's next exception incoming and also asks UI manager to show
 it to user, we queue it,
 letting user to deal with first one.. (or we delay the popup , say 1
 each 5 seconds).
 and finally, a queue should have some reasonable limit, after which we
 stop queuing , because again, user certainly won't be willing to waste
 his time dealing with 1000 exceptions of same kind one by one. It
 doesn't makes sense anyways.

 In such case we can just ignore halt and let program continue (but
 increment some counter to show user how many of them are there).
 If exception is different (an Error) then on queue overflow, i think
 it should terminate the process with exception (but of course, special
 care must be taken if process is UI process).
 Of course making it too smart is pointless, because it is impossible
 to predict whether it is good idea
 to terminate process or letting it continue to run in case of exception.
 But for that we can have settings and options, to tune that at user's
 discretion, as well as default
 settings on a per-exception class base.




 anyhow, just musing  -ben




 i know by myself how annoying it can be (up to unresponsive image)
 and i think most of us is facing such situation time to time (heh..
 just yesterday we had it with Camillo while hacking ocompletion
 stuff).
 i learned to be careful and avoid such situations.. but sometimes it
 is hard and better tooling support will be helpful, no doubt.





 Another use case that just happened to me.  This is not 'halt' related
 but
 just a typo...  (which suddenly makes the whole system feel a bit
 fragile)
 Working on a small new feature in the drawing loop of Roassal, I would
 guess
 all that I did was leave out a full stop at the end a line.  So the
 image
 locked and crashed after about 20 seconds.  Unfortunately now the image
 is
 crashing every time I try to open it.  Some mechanism to throttle and
 temporarily ignore the error to allow me to rectify the problem would
 have
 been immensely useful.  In this case, perhaps something like blocking the
 main UI loop and presenting a modal window of a very basic self contained
 text editor on the offending method.
 At 

Re: [Pharo-project] New Text Completion suggestions

[Eliot Miranda]

On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko siguc...@gmail.com wrote:

 (a bit orthogonal)
 i don't understand why we cannot have own, consistent set which is good
 for us?
 vim, emacs..


better use sets which are already extremely familiar than invent yet
another set.  to those of us who use these editors (and we are legion)
these sets have long become almost subconscious to use.

why this is so important ? Those editors were not written for editing
 smalltalk code in mind..
 they are best suited for big, hundreds lines of code, files..


they're the two most popular editors of their type.  lots of people use
them for other languages without IDE support.  They provide convenient
power features such as pattern replacement.  Not often I find myself filing
out Smalltalk code and editing it with vim (sadly I've never learned emacs).


 while something like that in our case is an exception rather than norm.
 So, why some people striving for having same keys as there? Just
 because they get used  to them?

 Seriously vim? A modal editor which is invented for editing files on
 obscure terminals, where you don't even have a cursor keys on
 keyboard? I pass..

 Just give me a decent editor with good cursor navigation, selection
 and undo/redo/find/replace, that's all i need.



 --
 Best regards,
 Igor Stasenko.




-- 
best,
Eliot

Re: [Pharo-project] numLiterals 0 is that possible?

[Eliot Miranda]

On Fri, Aug 17, 2012 at 1:42 PM, Mariano Martinez Peck 
marianop...@gmail.com wrote:

 Hi guys. Right now we have

 methodClass
 answer the class that I am installed in
 ^self numLiterals  0
  ifTrue: [ (self literalAt: self numLiterals) value ]
 ifFalse: [ nil ]

 But of course my image has no method with 0 literals:

 (CompiledMethod allInstances select: [:each | each numLiterals = 0 ]) size
 - 0

 So...can this really happen? or I can just remove the if ?


Yes it could happen.  For example, i the Newspeak implementation above
Squeak these is a collection of inst-var accessors that are shared through
all Newspeak classes in the system.  These have a nil methodClass.  If one
wanted to save space they could have no methodClass instead of nil in the
methodClass slot.  (Note that the above works for these since nil value =
value).  So IMO its a harmless piece of defensice programming.  IIABDFI (If
it ain't broke don't fix it).




 thanks

 --
 Mariano
 http://marianopeck.wordpress.com




-- 
best,
Eliot

[Pharo-project] new Cog VMs

[Eliot Miranda]

Hi All,

   please find new VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2585/.
 These VMs try and fix an occasional crash (try because the fix doesn't
handle all cases yet), and at least turn it into an orderly exit with error
message (no room on youngReferrers list/youngReferrers list
overflowed) instead of a hard crash.


Cog VM binaries as per VMMaker.oscog-eem.201/r2585.

Make sure youngReferrersList has room for every method since become/cache
implicit receiver can cause any method to gain a young reference.  Do so
by counting methods in the zone.  Make overflowing the youngReferrers list
a hard error (appears to happen quite often in Newspeak code).

Fix assert in interpretMethodFromMachineCode.

Fix bug in changeClassFrom:to: if receiver is a compact class
instance with a large header.
-- 
best,
Eliot

Re: [Pharo-project] Playing with a declarative startup/shutdown subscription mechanism

[Eliot Miranda]

On Sun, Aug 5, 2012 at 2:57 PM, Igor Stasenko siguc...@gmail.com wrote:

 On 5 August 2012 23:37, Stéphane Ducasse stephane.duca...@inria.fr
 wrote:
  I have the impression that you will need a finer order at least for the
 kernel.
  so putting
  SomeClassstartUp: quitting
systemShutdown: #kernel priority: 1000
self blahblah.
 
  looks to me the way to go and yes we should clean that part two.


  Now what is the gain to have pragma and not just a class side method
 returning a number?
 
  Stef
 
 the downside of it, that you apparently more slower than explicit
 subscription (you have to scan
 over all methods with such pragma).


No.  Registration can be done when methods are added or removed.  Pragmas
don't have to be scanned on each invocation.  Instead the need is for a
hook when methods are added or removed, and such hooks exist.


 i cannot remember what solution i proposed.. ah ok.. i recall.
 i proposed to introduce a session-awareness. i.e. an object holds a
 reference to a session object
 and before each access to its some session-specific resource it should
 check if session has changed or not.
 and if session is obsolete, then you know that you must reinitialize
 (meaning do a startup).
 this is what i did in NB: it does not registering for startup, but
 instead it initializing at first attempt to use it. So if nobody using
 it, nothing happens (means no extra cycles burned at startup for
 nothing).
 This also solves nicely a problem with priority of service initialization:
 - imagine service A requires service B to function,
 but user code attempts to access a service A first. Now since service
 A will try to access a service B first,
 as result, a service B will be naturally (re)initialized first.
 Like that, you don't even need to think (or make sure), who should be
 (re)initialized first, because chain of priority automatically adjusts
 itself according to program flow.

 --
 Best regards,
 Igor Stasenko.




-- 
best,
Eliot

Re: [Pharo-project] Playing with a declarative startup/shutdown subscription mechanism

[Eliot Miranda]

On Sun, Aug 5, 2012 at 2:15 PM, Guillermo Polito
guillermopol...@gmail.comwrote:

 Hi!

 Last days I was playing to replace the image startup/shutdown mechanism
 via a pragma subscription because I was pissed off with how difficult is to
 integrate the change of a new startup in the system. The idea is:
 - reduce the mess on subscription/unsubscription, initialization, etc
 - reduce dependencies of external packages in core packages.

 This way, if you want to subscribe a class side method to be executed on
 startup, you annotate it:

 SomeClassstartUp: resuming
 systemStartup: #application
 self blahblah.

 SomeClassstartUp: quitting
 systemShutdown: #kernel
 self blahblah.




You need before: and after:.  IMO, you also need to support multiple
befores or afters.  I think that's much better than a priority scheme.

Also, as I said in response to Igor's message, you can register when pragma
methds are added/removed, rather than looking for methods when
initialization/shutdown is run.



 Now, instead of an order in classes startup, I played with the idea of
 having run levels (which I named #kernel, #application and #user because I
 was not inspired :P).  Then I replaced the whole system startup and It's
 working...

 The code is very simple, you can have a look at the category *System-Tasks
 * which can be downloaded from:

 MCGemstoneRepository
 location: 'http://ss3.gemstone.com/ss/PharoTaskForces'
  user: ''
 password: ''

 SLICE-Issue-666-Playing-With-startup-GuillermoPolito.2


 Be careful, that package contains the startup code + the replacement of
 the old startup by the new one :).

 Now, I'd like to have some feedback, u like it? u buy it? which should be
 the names for the run levels? how many run levels should we have? :P

 Cheers,
 Guille




-- 
best,
Eliot

Re: [Pharo-project] [squeak-dev] CompiledMethod#hash broken on CogVM r2559, Win7, Squeak 4.3

[Eliot Miranda]

On Mon, Jul 23, 2012 at 11:34 AM, Mariano Martinez Peck 
marianop...@gmail.com wrote:



 On Mon, Jul 23, 2012 at 8:08 PM, Eliot Miranda eliot.mira...@gmail.comwrote:

 Hi Marcel,

 that's because the old hash method is broken.  The Cog VM finally
 adds a correct bounds check that prevents byte access to the non-byte parts
 (literals) of a CompiledMethod.  Accessing the literals of a method via
 byte access gives access to the addresses of objects.  This is broken since
 the GC is a moving garbage collector and so addresses can change.  Hence a
 hash derived from such bytes is not stable.  See Kernel-eem.692 which
 provides the attached hash method.


 Hi Eliot. I remember seeing this discussion in the Pharo mailing list
 also. So...I guess we should commit that also in Pharo, right?


Yes.  Also the bug fixes in Kernel-eem.700  Kernel-eem.703.





 On Sun, Jul 22, 2012 at 7:10 AM, Marcel Taeumel 
 marcel.taeu...@student.hpi.uni-potsdam.de wrote:

 Hi!

 It is not possible to compute the hash value of a CompiledMethod instance
 with the CogVM r2559 on a Windows 7 machine using a Squeak 4.3 image.

 Should it be possible despite of all enhancements in the Cog VM?

 Best,
 Marcel

 22 July 2012 4:06:54.988 pm

 VM: Win32 - Smalltalk
 Image: Squeak4.3 [latest update: #11860]

 SecurityManager state:
 Restricted: false
 FileAccess: true
 SocketAccess: true
 Working Dir C:\Tools\vivide_dev
 Trusted Dir C:\Tools\vivide_dev\Marcel
 Untrusted Dir C:\Users\Marcel\Documents\My Squeak

 CompiledMethod(Object)error:
 Receiver: (Morph#drawOn: a CompiledMethod(337))
 Arguments and temporary variables:
 aString:'subscript is out of bounds: 1'
 Receiver's instance variables:
 (Morph#drawOn: a CompiledMethod(337))

 CompiledMethod(Object)errorSubscriptBounds:
 Receiver: (Morph#drawOn: a CompiledMethod(337))
 Arguments and temporary variables:
 index:  1
 Receiver's instance variables:
 (Morph#drawOn: a CompiledMethod(337))

 CompiledMethod(Object)basicAt:
 Receiver: (Morph#drawOn: a CompiledMethod(337))
 Arguments and temporary variables:
 index:  1
 Receiver's instance variables:
 (Morph#drawOn: a CompiledMethod(337))

 CompiledMethod class(ByteArray class)hashBytes:startingWith:
 Receiver: CompiledMethod
 Arguments and temporary variables:
 aByteArray: (Morph#drawOn: a CompiledMethod(337))
 speciesHash:244619647
 byteArraySize:  43
 hash:   244619647
 low:nil
 pos:1
 Receiver's instance variables:
 superclass: ByteArray
 methodDict: a MethodDictionary(size 190)
 format: 3586
 instanceVariables:  nil
 organization:   ('accessing' clearFlag defaultSelector
 dragLabel endPC flag
 flush...etc...
 subclasses: nil
 name:   #CompiledMethod
 classPool:  a Dictionary(#LargeFrame-56
 #SmallFrame-16 )
 sharedPools:nil
 environment:Smalltalk globals a SystemDictionary
 with lots of globals
 category:   #'Kernel-Methods'

 CompiledMethod(ByteArray)hash
 Receiver: (Morph#drawOn: a CompiledMethod(337))
 Arguments and temporary variables:

 Receiver's instance variables:
 (Morph#drawOn: a CompiledMethod(337))

 UndefinedObjectDoIt
 Receiver: nil
 Arguments and temporary variables:

 Receiver's instance variables:
 nil

 Compilerevaluate:in:to:notifying:ifFail:logged:
 Receiver: a Compiler
 Arguments and temporary variables:
 textOrStream:   a ReadWriteStream '(Morph#drawOn:)
 hash'
 aContext:   nil
 receiver:   nil
 aRequestor: a SmalltalkEditor
 failBlock:  [closure] in [] in
 SmalltalkEditor(TextEditor)evaluateSelectionAnd...etc...
 logFlag:true
 methodNode: DoIt
 ^ (Morph  #drawOn:) hash
 method: (UndefinedObject#DoIt a
 CompiledMethod(1506))
 value:  nil
 toLog:  nil
 itsSelection:   nil
 itsSelectionString: nil
 Receiver's instance variables:
 sourceStream:   a ReadWriteStream '(Morph#drawOn:)
 hash'
 requestor:  a SmalltalkEditor
 class:  UndefinedObject
 category:   nil
 context:nil
 parser: a Parser

 [] in SmalltalkEditor(TextEditor)evaluateSelectionAndDo:
 Receiver: a SmalltalkEditor
 Arguments and temporary variables:
 error during printing
 Receiver's instance variables:
 morph

Re: [Pharo-project] New VMs at http://www.mirandabanda.org/files/Cog/VM/VM.r2559/

[Eliot Miranda]

On Wed, Jul 18, 2012 at 2:03 AM, Camillo Bruni camillobr...@gmail.comwrote:

 I assume they don't include the FilePlugin changes?
 Because then they will only work under Pharo 1.4 and before!


Which specific changes Camilo?  If they're not in I'll integrate them asap.



 On 2012-07-18, at 04:21, Sean P. DeNigris wrote:
  Eliot Miranda-2 wrote
 
  Add -blockonerror flag to Unix  Mac VMs to allow attaching gdb on
  error/segv.
 
 
  Cool!! Thanks, Eliot
 
  --
  View this message in context:
 http://forum.world.st/New-VMs-at-http-www-mirandabanda-org-files-Cog-VM-VM-r2559-tp4636053p4640457.html
  Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
 





-- 
best,
Eliot

Re: [Pharo-project] New VMs at http://www.mirandabanda.org/files/Cog/VM/VM.r2559/

[Eliot Miranda]

The unix VMs in this build are defunct.  The UnixOSProcessPlugin was
broken.  Please find functional ones in
http://www.mirandabanda.org/files/Cog/VM/VM.r2562.

On Thu, Jun 21, 2012 at 6:58 PM, Eliot Miranda eliot.mira...@gmail.comwrote:

 http://www.mirandabanda.org/files/Cog/VM/VM.r2559/

 CogVM binaries as per VMMaker.oscog-eem.163/r2559.

 Make wakeHighestPriority filter-out zombie processes; fixes Newspeak/Glue
 crash.
 Add -blockonerror flag to Unix  Mac VMs to allow attaching gdb on
 error/segv.
 Make the sigsegv handler catch SIGILL and SIGBUS on Unix and Mac.
 Add 64-bit file support to linux builds.
 Fix sqUnixX11.c ClipChildren to ClipByChildren.

 --
 best,
 Eliot




-- 
best,
Eliot

Re: [Pharo-project] can someone explain me this method?

[Eliot Miranda]

On Fri, Jul 13, 2012 at 10:51 AM, Camillo Bruni camillobr...@gmail.comwrote:

 Cool thanks everyone for the references :D

 We will pu that into the sources

 On 2012-07-13, at 19:47, Nicolas Cellier wrote:

  The first numbers are quite easy to guess without reading any reference :

 if you have a major in astronomy, sure :P

  - 400 years span 146097 days in gregorian calendar.
  - 100 years span 36524 days, except every 400 years.
  - 4 years span 1461 days, except every 100 years.
  - 1 year span 365 days, except every four years

 well indeed, not that hard :P, but when you're in midst of a mind-boggling
 refactoring
 you don't waste time to understand these details :P


:)

Here's an analogous method in VisualWorks.  They don't bother to document
seconds per day (86400).

TimeZonetimestampToSeconds: aTimestamp
 Convert a Timestamp in to seconds starting from the Smalltalk epoch in
UTC.
  Since we do not know leap-seconds in UTC, Answer the number of seconds
since January 1, 1901.
  Same as 'self asDate asSeconds + self asTime asSeconds' 

| yearIndex absDays seconds |
yearIndex := aTimestamp year - 1901.
absDays := yearIndex * 365  elapsed years
+ (yearIndex // 4)  ordinary leap years
+ ((yearIndex + 300) // 400)  leap centuries, first one is 2000, i.e.
yearIndex = 99
- (yearIndex // 100)  non-leap centuries
+ aTimestamp day - 1
+ (aTimestamp firstDayOf: aTimestamp month).
seconds := aTimestamp hour * 60 +
aTimestamp minute * 60 +
aTimestamp second.
do it this way to minimize large arithmetic
^absDays * 86400 + seconds

But  I like Same as 'self asDate asSeconds + self asTime asSeconds'  since

DateasSeconds
Answer the seconds between the time that 1901 began
and the same time in the receiver's day.

^self asTimestamp asSeconds

and

TimestampasSeconds
Answer the number of seconds since January 1, 1901.
Same as 'self asDate asSeconds + self asTime asSeconds'

^TimeZone default timestampToSeconds: self

So the documentation still leaves something to be desired :)

It is perhaps unfortunate that manifest constants in class variables cost
more than literals because of the indirection through the association.  I
did an inlining scheme in VisualWorks many years ago that depended on
automatic recompilation when read-only bindings were changed (since the
scope of these bindings is limited its quick to find affected methods).  It
depended on the method including the binding in its literals even though
the compiler inlined the value of the binding, and it depended on access to
source (since the points where the variable is inlined are not marked in
the bytecode).  I still think there's benefit here; even a JIT needs to
know what bindings are read-only and a write-barrier to be able to inline
the values of globals.  But it has a lot of impact for not very much
performance (given that in performance-critical parts of the system people
have already inlined by hand, as in the above).  So I suppose it will
remain a fun experiment.

 For months and days, the tricks are less trivial...
 
  Nicolas
 
 
  2012/7/13 Sven Van Caekenberghe s...@beta9.be:
  Yeah, but sometimes a clever algorithm comes from a book, so to speak.
 
  Giving the variables long names, or the constants names, would not make
 that much difference, it would still be pretty hard to understand.
 
  ZTimestamp classwithJdn: jdn dayMonthYearDo: block
 Return the value of executing block with the Gregorian Calender
 day, month and year as arguments,
 as computed from my Julian Day Number, jdn.
 See
 http://en.wikipedia.org/wiki/Julian_date#Gregorian_calendar_from_Julian_day_number
 
 
 | j g dg c dc b db a da y m d |
 j := jdn + 32044.
 g := j // 146097.
 dg := j \\ 146097.
 c := ((dg // 36524) + 1) * 3 // 4.
 dc := dg - (c * 36524).
 b := dc // 1461.
 db := dc \\ 1461.
 a := ((db // 365) + 1) * 3 // 4.
 da := db - (a * 365).
 y := (g * 400) + (c * 100) + (b * 4) + a.
 m := da * 5) + 308)) // 153) - 2.
 d := da - ((m + 4) * 153 // 5) + 122.
 ^ block
 value: d + 1
 value: ((m + 2) \\ 12) + 1
 value: (y - 4800 + ((m * 2) // 12))
 
  On 13 Jul 2012, at 17:53, Camillo Bruni wrote:
 
  comments? decent variable names? no magic numbers?
  NOW you can find NONE of that in dayMonthYearDo!
 
 
  ==
  dayMonthYearDo: aBlock
   Evaluation the block with three arguments: day month, year.
 
   | l n i j dd mm  |
   l := jdn + 68569.
   n := 4 * l // 146097.
   l := l - (146097 * n + 3 // 4).
   i := 4000 * (l + 1) // 1461001.
   l := l - (1461 * i // 4) + 31.
   j := 80 * l // 2447.
   dd := l - (2447 * j // 80).
   l := j // 11.
   mm := j + 2 - (12 * l).
    := 100 * (n - 49) + i + l.
 
   ^ aBlock
   value: dd
   value: mm

[Pharo-project] start-up and shut-down lists

[Eliot Miranda]

Hi All,

I'm profiling image startup and consequently want to pause a
MessageTally during a snapshot.  So I want to add MessageTally to the
StartUpList immediately after Delay (the first entry in StartUpList) and to
the ShutDownList immediately before Delay.  But when I look at the
SmalltalkImage accessor I see some confusion:

SmalltalkImageadd: aClass toList: startUpOrShutDownList after: predecessor
Add the name of aClass to the startUp or shutDown list.
Add it after the name of predecessor, or at the end if predecessor is nil.

| name earlierName |
name := aClass name.
(self at: name ifAbsent: [nil]) == aClass ifFalse:
[self error: name , ' cannot be found in Smalltalk dictionary.'].
predecessor == nil
ifTrue: [No-op if alredy in the list.
(startUpOrShutDownList includes: name) ifFalse:
[startUpOrShutDownList == StartUpList
ifTrue: [Add to end of startUp list
startUpOrShutDownList addLast: name]
ifFalse: [Add to front of shutDown list
startUpOrShutDownList addFirst: name]]]
ifFalse: [Add after predecessor, moving it if already there.
earlierName := predecessor name.
(self at: earlierName) == predecessor ifFalse:
[self error: earlierName , ' cannot be found in Smalltalk dictionary.'].
(startUpOrShutDownList includes: earlierName) ifFalse:
[self error: earlierName , ' cannot be found in the list.'].
startUpOrShutDownList remove: name ifAbsent:[].
startUpOrShutDownList add: name after: earlierName]

In the predecessor == nil arm adding to the StartUpList adds at the end and
adding to the ShutDownList adds at the beginning, which makes sense, at
least to me.  But if predecessor is not nil then adding to either adds
after.  The asymmetry is troubling.  I guess in the name of stability the
only way to solve this is to add an explicit add:toList:before: and sugar
(add:toStartUpListBefore: add:toShutDownListBefore:).  So what's the
rationale for the asymmetry, or is it an unintentional mistake?
-- 
best,
Eliot

Re: [Pharo-project] Reify Changes file?

[Eliot Miranda]

On Mon, Jul 2, 2012 at 3:14 AM, Guillermo Polito
guillermopol...@gmail.comwrote:

 What if we remove the changes logging from SmalltalkImage and make it part
 of a ChangesLog object?  I'm looking at some SystemChangeNotifier
 subscription ashes, and this could fix two things in one shot :)


How will you do crash recovery?

-- 
best,
Eliot

[Pharo-project] New VMs at http://www.mirandabanda.org/files/Cog/VM/VM.r2559/

[Eliot Miranda]

http://www.mirandabanda.org/files/Cog/VM/VM.r2559/

CogVM binaries as per VMMaker.oscog-eem.163/r2559.

Make wakeHighestPriority filter-out zombie processes; fixes Newspeak/Glue
crash.
Add -blockonerror flag to Unix  Mac VMs to allow attaching gdb on
error/segv.
Make the sigsegv handler catch SIGILL and SIGBUS on Unix and Mac.
Add 64-bit file support to linux builds.
Fix sqUnixX11.c ClipChildren to ClipByChildren.

-- 
best,
Eliot

Re: [Pharo-project] Process Tests and

[Eliot Miranda]

On Thu, Jun 14, 2012 at 2:34 AM, Frank Shearar frank.shea...@gmail.comwrote:

 On 13 June 2012 23:15, Eliot Miranda eliot.mira...@gmail.com wrote:
 
 
  On Wed, Jun 13, 2012 at 7:35 AM, Frank Shearar frank.shea...@gmail.com
  wrote:
 
  On 2 June 2012 09:28, Stefan Marr smallt...@stefan-marr.de wrote:
   Hi Sean:
  
   On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote:
  
   During the process, I noticed that the Blue Book specifies that #fork
   returns the block itself (pg. 252), while in Pharo it returns the
   process
   (see #testFork in the slice). Should our implementation be changed to
   match the Blue Book?


Sorry to reply so late.  I think the blue book definition is broken.  fork
should answer the process.  It has been changed to do so in VisualWorks for
a long time.  I think the blue book definition is simply a bug.  It can
easily be implemented in the caller using yourself, i.e.

 [...] fork; yourself

answers the block if one needs it.

 
   Why would it be desirable to have the block?
   How would you obtain the process object after your change?
  
   Having the process directly is useful to do fork/join style
 operations.
 
  How do you #join Processes? I can't see anything in Process' protocol
  for doing so. so what am I missing?
 
 
  Nothing.  Theres no support for join.  You have to roll your own.

 OK, that's what I thought. Stefan's comment intrigued me.

 It would be kind've handy to be able to say - even though we don't use
 native threads - something like this:

 (0..10).map {|i|
Thread.new { sleep(1); i }
 }.map {|t| t.value}

 only in a decent language:

 ((0 to: 10)
collect: [:i | [(Delay forSeconds: 1) wait. i] fork])
  collect: [:p | p value].

 frank

 
 
  frank
 
   Best regards
   Stefan
  
   --
   Stefan Marr
   Software Languages Lab
   Vrije Universiteit Brussel
   Pleinlaan 2 / B-1050 Brussels / Belgium
   http://soft.vub.ac.be/~smarr
   Phone: +32 2 629 2974
   Fax:   +32 2 629 3525
  
  
 
 
 
 
  --
  best,
  Eliot
 




-- 
best,
Eliot