Eliot Miranda uploaded a new version of VMConstruction-Plugins-OSProcessPlugin to project OSProcessPlugin:
http://www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins-OSProces…
==================== Summary ====================
Name: VMConstruction-Plugins-OSProcessPlugin.oscog-eem.35
Author: eem
Time: 4 May 2012, 8:54:58 am
UUID: 15acec73-e0e7-4cc0-a521-1c4204a4b5b7
Ancestors: VMConstruction-Plugins-OSProcessPlugin.oscog-eem.34
Merge changes from VMConstruction-Plugins-OSProcessPlugin-dtl.35
Dave Lewis uploaded a new version of VMConstruction-Plugins-OSProcessPlugin to project OSProcessPlugin:
http://www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins-OSProces…
==================== Summary ====================
Name: VMConstruction-Plugins-OSProcessPlugin-dtl.35
Author: dtl
Time: 3 May 2012, 10:37:36 am
UUID: 1b11f141-e2ad-407c-8f7c-65a83faad075
Ancestors: VMConstruction-Plugins-OSProcessPlugin-dtl.34
OSProcessPlugin 4.4.11
Fix bug in UnixOSProcessPlugin>>primitiveChdir, was answering errno on success and nil on failure, should be the reverse. Bug has been present since at least 2006. Thanks Damien Cassou for finding the bug.
Hi,
I can't find any getenv primitive that would allow me to access
environment an variable value from its name. This could be really
helpful to get the HOME directory for example. Does one such primitive
exist? If not, why? It looks trivial to implement for linux, and it is
potentially also easy on Windows and Mac OS. I'm willing to try if
necessary.
Thank you
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry
On Tue, May 1, 2012 at 9:13 AM, Mariano Martinez Peck <marianopeck(a)gmail.com
> wrote:
>
>
> On Tue, May 1, 2012 at 6:09 PM, Mariano Martinez Peck <
> marianopeck(a)gmail.com> wrote:
>
>> Hi guys. I noticed stef did this issue:
>> http://code.google.com/p/pharo/issues/detail?id=5642
>> However, now I have the following test that fails in Pharo 2.0 but works
>> fine in 1.4:
>>
>> | string context |
>> string := 'test'.
>> context := [self class. string asUppercase] asContext.
>> self assert: (context tempNamed: 'string') = 'test'
>>
>> the current implementation of #tempNamed: is:
>>
>> tempNamed: aName
>> "Returns the value of the temporaries, aName."
>> "Implementation notes: temporary initialization in blocks simply uses
>> pushNil to allocate and initialize each temp. So if one inspects [|a|a:=2]
>> and sends it self method symbolic you get:
>>
>> 13 <8F 00 00 05> closureNumCopied: 0 numArgs: 0 bytes 17 to 21
>> 17 <73> pushConstant: nil
>> 18 <77> pushConstant: 2
>> 19 <81 40> storeIntoTemp: 0
>> 21 <7D> blockReturn
>> 22 <7C> returnTop
>>
>> And when we check self asContext pc we get 17, which is *before* the
>> nil is pushed. Therefore we should pay attention when querying a temporary
>> if the temporary allocation was executed."
>>
>> | index |
>> index := (self tempNames indexOf: aName).
>> ^ index >= stackp
>>
>
>
> Maybe the solution is to use #> rather than #>= ?
>
right. But tempNames is fundamentally broken for closures. It does not
answer temps in indirection vectors. That is the whole point of
schematicTempNamesString; it gives the topology of temps in a method. e.g.
(where => means printIt returns...)
(Collection>>#inject:into:) methodNode schematicTempNamesString =>
'thisValue binaryBlock (nextValue)[each binaryBlock (nextValue)]'
This says that
a) at method level there are three temps, thisValue, binaryBlock and an
indirection vector, and in the indirection vector is one temp named
nextValue.
b) in the block in inject:into: there are three temps, each (the argument),
binaryBlock and an indirection vector, and in that indirection vector is a
temp named nextValue.
This is all orchestrated by DebuggerMethodMap, so that
aContext method debuggerMap tempNamesForContext: aContext
answers a list of the flattened temp names in a context (flattening out
indirection vectors) and for the above would answer either #('thisValue'
'binaryBlock' 'nextValue') or #('each' 'binaryBlock' 'nextValue'), and
| map |
map := aContext method debuggerMap.
map namedTempAt: ((map tempNamesForContext: aContext) indexOf:
aTempName) in: aContext
gets the temp from the unflattened temps in a context. This is how the
debugger accesses temp names.
So you need to throw away the broken tempName: implementation and use
DebuggerMethodMap or some parse over schematicTempNamesString, because
*with closures temps are not simply at contiguous offsets on the stack*.
Make sense?
Now, one good way to understand this is through examples. inject:into: is
the canonical simple example I've used for years. But we can find more
complex examples that may help. So this query looks for all methods that
contain a bytecode to create an indirection vector with 2 or more elements:
SystemNavigation new browseAllSelect:
[:m| | is |
is := InstructionStream on: m.
is scanFor: [:b| b = 138 and: [is followingByte between: 2 and: 127]]]
and the simplest example in a trunk 4.3 image I find is:
Bag>>sum
"Faster than the superclass implementation when you hold many instances of
the same value (which you probably do, otherwise you wouldn't be using a
Bag)."
| sum first |
first := true.
contents keysAndValuesDo: [ :value :count |
first
ifTrue: [ sum := value * count. first := false ]
ifFalse: [ sum := sum + (value * count) ] ].
first ifTrue: [ self errorEmptyCollection ].
^sum
which needs a two-element indirection vector because the block [ :value
:count |...] assigns to both sum and first. Hence
(Bag>>#sum) methodNode schematicTempNamesString => '(sum
first)[value count (sum first)]'
So in an activation of Bag>>sum the value of first is (sumContext tempAt:
1) at: 2 (cuz tempAt: 1 is the indirection vector represented as (sum
first) in schematic temps, and first is the second element. But in an
activation of the block in Bag>>sum the value of first is (sumBlockContext
tempAt: 3) at: 2.
I can keep repeating myself until I'm blue in the face, but y'all have to
put in the effort to understand this simple scheme. Temps that are
modified after they are closed-over end up in indirection vectors.
>
>
>> ifTrue: [ nil]
>> ifFalse: [self tempAt: (self tempNames indexOf: aName)]
>>
>>
>> and previously it was:
>>
>> tempNamed: aName
>> ^self tempAt: (self tempNames indexOf: aName)
>>
>>
>> ideas?
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
--
best,
Eliot
Hi Esteban:
I just downloaded a Cog-Mac-Cocoa-blessed from: https://ci.lille.inria.fr/pharo/job/Cog-Mac-Cocoa-blessed/
It tells me, it is currently 19days old.
And it ignores the -headless parameter.
The old VM I used so far is from Jul 6th and does execute headless without problems.
I did not find the mail on the list that was naming the primitives to get more version infos out of the VMs, sorry.
The latest StackVM also got that problem, but it works with the version from July.
Is there actually something like -version on the command line to ask for the exact version infos?
I checked -help, which also offers a lot less info then it used to. It still mentions -headless, but misses the options below.
Best regards
Stefan
Missing help for commandline options:
-breaksel selector set breakpoint on send of selector
-eden <size>[mk] set eden memory to bytes
-leakcheck num check for leaks in the heap
-stackpages num use n stack pages
-codesize <size>[mk] set machine code memory to bytes
-sendtrace[=num] enable send tracing (optionally to a specific value)
-tracestores enable store tracing (assert check stores)
-cogmaxlits <n> set max number of literals for methods compiled to machine code
-cogminjumps <n> set min number of backward jumps for interpreted methods to be considered for compilation to machine code
-pathenc <enc> set encoding for pathnames (default: macintosh)
--
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
Hi,
I have found the origin of various crashes in the Squeak VM, which is related to the JPEGReadWriter2Plugin.
The hunt begun with Juan's Cuis 4.0 release, see the emails exchanged below and the description.
I have attached the fixed C source, but the fix should go in the VM sources, because the code is
generated as I see. Please include the fix in the VM sources.
Regards,
Andras Pahi
----- Original Message -----
From: Juan Vuletich (mail lists)
To: Páhi András
Sent: Thursday, April 26, 2012 9:26 PM
Subject: Re: Cuis 4.0 crash on startup
Wow Páhi! This is great! Please send all this to the vm-dev mail list, and ask for it to be included (or directions to do it yourself).
It is my bug in the end... I wrote JPEGReadWriter2Plugin about 10 years ago...
Cheers,
Juan Vuletich
Quoting Páhi András <pahia(a)t-online.hu>:
Hi,
Replace the winbuild/src/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.c file with the attached file,
recompile the Squeak VM and Cuis 4.0 rocks. In the plugin there was a 1 off access in the formBits array.
Because the code is generated, it needs to be corrected in the VM sources.
How can I got there ?
Executing several times World buildMagnifiedBackgroundImage in Cuis 3.3 crashed the Squeak VM.
I exported the background image data, converted from JPEG to other format (BMP/PNG) and set the new
format image to World backgroundImageData:. Everything worked as expected.
I replaced the formBits array accesses in JPEGReadWriter2Plugin2.c with my routines, checking the indices
and reporting off-array access attempts. Then I fixed the places in the C source.
Regards,
Andras Pahi
----- Original Message -----
From: Juan Vuletich (mail lists)
To: Páhi András
Sent: Thursday, April 26, 2012 12:47 PM
Subject: Re: Cuis 4.0 crash on startup
Great. Thanks. You might ask for help or directions in the vm-dev mail list. I'm sure that several people are at least aware of the bug.
Cheers,
Juan Vuletich
Quoting Páhi András <pahia(a)t-online.hu>:
Hi,
Thank you for your reply. I will dig into the issues with the Windows VM.
Regards,
Andras Pahi
----- Original Message -----
From: Juan Vuletich (mail lists)
To: Páhi András
Sent: Thursday, April 26, 2012 11:59 AM
Subject: Re: Cuis 4.0 crash on startup
Hi Páhi,
There is some problem with that Windows VM, not limited to Cuis. If you google "Squeak VM 4.1.1 windows crash" you'll find many results, for example http://bugs.squeak.org/view.php?id=7585http://bugs.squeak.org/bug_view_advanced_page.php?bug_id=7686 and http://bugs.squeak.org/view.php?id=7523 .
I'm not involved in the development of the Windows VM, all I can do is recommend using Cog until this is fixed somehow.
Regards,
Juan Vuletich
Quoting Páhi András <pahia(a)t-online.hu>:
Hi,
I have just gave a shoot on Cuis 4.0 using SqueakVM 4.1.1 on Windows.
It even does not start, the crash dump is attached, but with the latest
Cog VM it runs fine.
I checked the older Cuis 3.3 image with the same SqueakVM, it runs fine.
Regards,
Andras Pahi
Cheers,
Juan Vuletich
Hi,
I added AioPlugin and SqueakSSL plugins in Cocoa builds.
Aio tests in OSProcess are green, but some other fails, and I don't know the reason.
Also, Zodiac tests are all green, but I think there are things missing.
Can you test and provide feedback?
link:
https://ci.lille.inria.fr/pharo/job/Cog-VM/Architecture=32,OS=mac/lastSucce…
Thanks,
Esteban
Dave Lewis uploaded a new version of VMConstruction-Plugins-AioPlugin to project AioPlugin:
http://www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-dtl.…
==================== Summary ====================
Name: VMConstruction-Plugins-AioPlugin-dtl.14
Author: dtl
Time: 1 May 2012, 8:30:17 am
UUID: 965d54b7-4309-42fd-adb0-64400d3c780b
Ancestors: VMConstruction-Plugins-AioPlugin-EstebanLorenzano.13
AioPlugin 2.2.6
Fix #versionString implementation to match OSProcessPlugin (value declared on instance side only).
Remove remaining references to SQAIO_H, no longer required.