squeak : Messages : 166335-166364 of 173664

On Tue, May 1, 2012 at 1:12 PM, Mariano Martinez Peck <marianopeck@...> wrote:

�

On Tue, May 1, 2012 at 9:29 PM, Eliot Miranda <eliot.miranda@...> wrote:

On Tue, May 1, 2012 at 9:13 AM, Mariano Martinez Peck <marianopeck@...> wrote:

On Tue, May 1, 2012 at 6:09 PM, Mariano Martinez Peck <marianopeck@...> 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. �

Ok, so I will integrate that as a first version.
�

But tempNames is fundamentally broken for closures.

Just to avoid confusing, #tempNames itself looks correct:

tempNames
�� "Answer a SequenceableCollection of the names of the receiver's temporary
�� variables, which are strings."

�� ^ self debuggerMap tempNamesForContext: self

Yes. �That's for ContextPart. �But it doesn't work for CompiledMethod, since temps may differ between a method and its blocks.

�

�

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

So #tempNames implementation is correct?

Yes.

�

�
�
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?

Actually, we do have:

namedTempAt: index
�� "Answer the value of the temp at index in the receiver's sequence of tempNames."
�� ^self debuggerMap namedTempAt: index in: self

and

namedTempAt: index put: aValue
�� "Set the value of the temp at index in the receiver's sequence of tempNames.
�� (Note that if the value is a copied value it is also set out along the lexical chain,
�� but alas not in along the lexical chain.)."
�� ^self debuggerMap namedTempAt: index put: aValue in: self

so, if I understand correctly all we need to do is to fix tempNamed: and tempNamedPut: so that the delegate to namedTempAt: and namedTempPut: rather than to tempAt: and tempAtPut: � ?

Yes.

�

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.

Thanks, I am trying to undersand and fix it :)
�

�

�� 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
--
Mariano
http://marianopeck.wordpress.com

--
best,

Eliot

#166336

From: Mariano Martinez Peck <marianopeck@...>
Date: Tue May 1, 2012 8:53 pm
Subject: Re: [Vm-dev] Re: [squeak-dev] Re: [Pharo-project] problem with tempNamed: in Pharo 2.0

marianopeck@...

�

But tempNames is fundamentally broken for closures.

Just to avoid confusing, #tempNames itself looks correct:

tempNames
�� "Answer a SequenceableCollection of the names of the receiver's temporary
�� variables, which are strings."

�� ^ self debuggerMap tempNamesForContext: self

Yes. �That's for ContextPart. �But it doesn't work for CompiledMethod, since temps may differ between a method and its blocks.
�

Right, but weren't we always talking about Contexts?� Because #tempNames of CompiledMethod is different than the thing of contexts, isn't it? It is related to the method trailer.� In fact, I have just checked Squeak 4.3 and CompiledMethod does not even implement #tempNames.� The implementation in Pharo is:

CompiledMethod >> #tempNames
�� self holdsTempNames ifFalse: [^#()].
�� ^self tempNamesString subStrings: ' '

how would it be the correct implementation then?

Thanks

--
Mariano
http://marianopeck.wordpress.com

#166337

From: Eliot Miranda <eliot.miranda@...>
Date: Tue May 1, 2012 11:08 pm
Subject: Re: [Vm-dev] Re: [squeak-dev] Re: [Pharo-project] problem with tempNamed: in Pharo 2.0

eliot.miranda@...

On Tue, May 1, 2012 at 1:53 PM, Mariano Martinez Peck <marianopeck@...> wrote:

�

But tempNames is fundamentally broken for closures.

Just to avoid confusing, #tempNames itself looks correct:

tempNames
�� "Answer a SequenceableCollection of the names of the receiver's temporary
�� variables, which are strings."

�� ^ self debuggerMap tempNamesForContext: self

Yes. �That's for ContextPart. �But it doesn't work for CompiledMethod, since temps may differ between a method and its blocks.
�

Right, but weren't we always talking about Contexts?� Because #tempNames of CompiledMethod is different than the thing of contexts, isn't it? It is related to the method trailer.� In fact, I have just checked Squeak 4.3 and CompiledMethod does not even implement #tempNames.� The implementation in Pharo is:

CompiledMethod >> #tempNames
�� self holdsTempNames ifFalse: [^#()].
�� ^self tempNamesString subStrings: ' '

how would it be the correct implementation then?

I don't think there is one. �Perhaps answering a set of all temp names, but that's not very useful.

�

Thanks

--
Mariano
http://marianopeck.wordpress.com

--
best,

Eliot

#166338

From: commits@...
Date: Tue May 1, 2012 11:55 pm
Subject: [squeak-dev] Daily Commit Log

commits@...

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours:

http://lists.squeakfoundation.org/pipermail/packages/2012-May/005313.html

Name: Collections-cmm.474
Ancestors: Collections-cmm.471, Collections-eem.473

Merged cmm.471 to allow, but not require, the system to support concatenation
semantics.

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2012-May/005314.html

Name: Collections-cmm.471
Ancestors: Collections-nice.470

Allow the system to be extended with concatenation semantics.

=============================================

Reply | Messages in this Topic (832)

#166339

From: Mariano Martinez Peck <marianopeck@...>
Date: Wed May 2, 2012 7:31 am
Subject: Re: [Vm-dev] Re: [squeak-dev] Re: [Pharo-project] problem with tempNamed: in Pharo 2.0

marianopeck@...

Actually, we do have:

namedTempAt: index
�� "Answer the value of the temp at index in the receiver's sequence of tempNames."
�� ^self debuggerMap namedTempAt: index in: self

and

namedTempAt: index put: aValue
�� "Set the value of the temp at index in the receiver's sequence of tempNames.
�� (Note that if the value is a copied value it is also set out along the lexical chain,
�� but alas not in along the lexical chain.)."
�� ^self debuggerMap namedTempAt: index put: aValue in: self

so, if I understand correctly all we need to do is to fix tempNamed: and tempNamedPut: so that the delegate to namedTempAt: and namedTempPut: rather than to tempAt: and tempAtPut: � ?

Yes.
�

Now I was thinking, what happens with the rest of the senders of tempAt: and tempAtPut: ?� do I need to do something with them?
�
Thanks

--
Mariano
http://marianopeck.wordpress.com

#166340

From: Chris Cunnington <smalltalktelevision@...>
Date: Wed May 2, 2012 12:57 pm
Subject: [squeak-dev] Squeak Oversight Board minutes � 5/01/12

smalltalktelevision@...

Squeak Oversight Board minutes � 5/01/12

Attending: Chris Muller, Colin Putney, Levente Uzonyi, Chris Cunnington,
Bert Freudenberg, Craig Latta

- the SOB meeting time is being changed tentatively to 1st and 3rd
Mondays noon in Los Angeles, so the next meeting is at May 7, 12pm L.A.,
Calif. time

- Colin is talking to Joyent [1] in Vancouver about hosting. They are a
large supporter of node.js

- Colin is compiling Cog for Illumos (a branch of Solaris) [2]

- It was agreed that the a transition from our current server to a new
server is required, as the current server hardware cannot run Cog (it's
an old AMD Athlon without SSE2)

- We discussed Squeak�s market position. Ideas around it being a
�flexible platform� and how it gives a user �complete control� were
emphasized. Squeak has been the point of departure for many innovative
projects: RoarVM, Scratch, Croquet, Pharo, Etoys

- Craig�s plans for Spoon in the coming year include porting the Naiad
module system to Squeak and other Smalltalks; and, making example
modules from existing Squeak code as a demonstration for other people to
get started

- The SOB is exploring the idea of having a Squeak event in North
American sometime in its tenure this year.

- There are plans to contact the SqueakFest [3] organizers to include a
track of programming for other kinds of Squeak projects than the educational

[1] http://www.joyent.com
[2] http://wiki.illumos.org/display/illumos/illumos+Home
[3] http://squeakland.org/squeakfest/about/

#166341

From: "H. Hirzel" <hannes.hirzel@...>
Date: Wed May 2, 2012 1:13 pm
Subject: Re: [squeak-dev] Squeak Oversight Board minutes – 5/01/12

hannes.hirzel@...

On 5/2/12, Chris Cunnington <smalltalktelevision@...> wrote:
> Squeak Oversight Board minutes – 5/01/12
>
> Attending: Chris Muller, Colin Putney, Levente Uzonyi, Chris Cunnington,
> Bert Freudenberg, Craig Latta
>
> - the SOB meeting time is being changed tentatively to 1st and 3rd
> Mondays noon in Los Angeles, so the next meeting is at May 7, 12pm L.A.,
> Calif. time
>
> - Colin is talking to Joyent [1] in Vancouver about hosting. They are a
> large supporter of node.js
>
> - Colin is compiling Cog for Illumos (a branch of Solaris) [2]
>
> - It was agreed that the a transition from our current server to a new
> server is required, as the current server hardware cannot run Cog (it's
> an old AMD Athlon without SSE2)
>
> - We discussed Squeak’s market position. Ideas around it being a
> “flexible platform” and how it gives a user “complete control” were
> emphasized. Squeak has been the point of departure for many innovative
> projects: RoarVM, Scratch, Croquet, Pharo, Etoys
>
> - Craig’s plans for Spoon in the coming year include porting the Naiad
> module system to Squeak and other Smalltalks; and, making example
> modules from existing Squeak code as a demonstration for other people to
> get started


"making example modules from existing Squeak code"
_excellent news_

--Hannes

> - The SOB is exploring the idea of having a Squeak event in North
> American sometime in its tenure this year.
>
> - There are plans to contact the SqueakFest [3] organizers to include a
> track of programming for other kinds of Squeak projects than the
> educational
>
> [1] http://www.joyent.com
> [2] http://wiki.illumos.org/display/illumos/illumos+Home
> [3] http://squeakland.org/squeakfest/about/
>
>

#166342

From: "Sean P. DeNigris" <sean@...>
Date: Wed May 2, 2012 1:38 pm
Subject: [squeak-dev] Re: AioPlugin and SqueakSSL plugin included in Cocoa (please test)

sean@...

EstebanLM wrote
>
> I added AioPlugin and SqueakSSL plugins in Cocoa builds.
>
Thanks, Esteban!!! This is so cool :) No more injecting a working copy of
ssl into all my vms... Your hard work is really, really appreciated. In the
Smalltalk tradition, I will buy you a beer next conference, lol!


EstebanLM wrote
>
> Can you test and provide feedback?
>
Abso-freakin-lutely (I don't know if that translates from American, but it's
a very big "yes")

Sean

--
View this message in context:
http://forum.world.st/AioPlugin-and-SqueakSSL-plugin-included-in-Cocoa-please-te\
st-tp4601461p4603232.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.

#166343

From: Chris Cunnington <smalltalktelevision@...>
Date: Wed May 2, 2012 4:07 pm
Subject: [squeak-dev] AioPlugin and SqueakSSL plugin included in Cocoa (please test)

smalltalktelevision@...

> I added AioPlugin and SqueakSSL plugins in Cocoa builds.

At the risk of seeming more obtuse than I usually am, why would I want SSL in an Apple VM unless I'm running an Apple server, which almost nobody does? SSL in a Linux VM, yea, OK, I get that. Does my desktop image running on my Mac need SSL for something?

Chris

Andy Dufresne: How can you be so obtuse?
Warden Samuel Norton: What? What did you call me?
Andy Dufresne: Obtuse. Is it deliberate?
Warden Samuel Norton: Son, you're forgetting yourself.
Andy Dufresne: The country club will have his old time cards. Records, W-2s with his name on them. Sir, if I ever get out, I'd never mention what happens here. I'd be just as indictable as you for laundering that money.

#166344

From: Bert Freudenberg <bert@...>
Date: Wed May 2, 2012 4:17 pm
Subject: Re: [squeak-dev] AioPlugin and SqueakSSL plugin included in Cocoa (please test)

bert@...

On 02.05.2012, at 18:07, Chris Cunnington wrote:

> I added AioPlugin and SqueakSSL plugins in Cocoa builds.

At the risk of seeming more obtuse than I usually am, why would I want SSL in an Apple VM unless I'm running an Apple server, which almost nobody does? SSL in a Linux VM, yea, OK, I get that. Does my desktop image running on my Mac need SSL for something?

Chris

You need SSL on both sides of a connection.

- Bert -

#166345

From: Chris Cunnington <smalltalktelevision@...>
Date: Wed May 2, 2012 4:53 pm
Subject: [squeak-dev] AioPlugin and SqueakSSL plugin included in Cocoa (please test)

smalltalktelevision@...

> You need SSL on both sides of a connection.

Connection of what?

Invariably a server is connecting to a browser. This implies a desktop/image based application. Outside of possibly Croquet, I don't know of any.

Chris

Warden Samuel Norton: I have to say that's the most amazing story I've ever heard. What amazes me most is that you were taken in by it.
Andy Dufresne: Sir?
Warden Samuel Norton: It's obvious this fellow Williams is impressed with you, he hears your tale of woe and naturally wants to cheer you up. He's young, not terribly bright, it's not surprising he wouldn't know what a state he put you in.
Andy Dufresne: Sir, he's telling the truth.
Warden Samuel Norton: Let's say for the moment this Blatch does exist. You think he'd just fall to his knees and cry: "Yes, I did it, I confess! Oh, and by the way, add a life term to my sentence."

#166346

From: Colin Putney <colin@...>
Date: Wed May 2, 2012 5:57 pm
Subject: Re: [squeak-dev] AioPlugin and SqueakSSL plugin included in Cocoa (please test)

colin@...

On Wed, May 2, 2012 at 9:53 AM, Chris Cunnington
<smalltalktelevision@...> wrote:
>> You need SSL on both sides of a connection.

> Invariably a server is connecting to a browser.

Not true. It's perfectly reasonable to write Smalltalk code to
download something over HTTPS. We do that for e.g., secure Monticello
repositories.

Colin

#166347

From: Chris Cunnington <smalltalktelevision@...>
Date: Wed May 2, 2012 6:04 pm
Subject: [squeak-dev] AioPlugin and SqueakSSL plugin included in Cocoa (please test)

smalltalktelevision@...

GitHub is likely the answer to my question.
You need SSL to push to GitHub.

FileTree with Cyprus is not ready to go, but I suppose it would need this.

On a 4.3 I loaded ConfigurationOfOSProcess and ran the tests. I got 192
run, 120 passes, 71 failures, 1 error.

Chris

TestRunner allInstances last failedList

   #('UnixProcessAccessorTestCase>>#testRedirectStdOutTo'
'UnixProcessTestCase>>#testCatAFile'
'UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDo'
'UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDoThenQuit'
'UnixProcessTestCase>>#testClassForkSqueak'
'UnixProcessTestCase>>#testClassForkSqueakAndDo'
'UnixProcessTestCase>>#testClassForkSqueakAndDoThenQuit'
'UnixProcessTestCase>>#testForkHeadlessSqueakAndDo'
'UnixProcessTestCase>>#testForkHeadlessSqueakAndDoThenQuit'
'UnixProcessTestCase>>#testForkSqueak'
'UnixProcessTestCase>>#testForkSqueakAndDo'
'UnixProcessTestCase>>#testForkSqueakAndDoThenQuit'
'UnixProcessTestCase>>#testHeadlessChild'
'UnixProcessTestCase>>#testRunCommand'
'UnixProcessTestCase>>#testSpawnTenHeadlessChildren'
'UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses01'
'UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses02'
'UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses03'
'UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses04'
'UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses05'
'UnixProcessUnixFileLockingTestCase>>#testFailFileLockOnLockedFile'
'UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedOverlappedRegion'
'UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedRegion'
'UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedSupersetRegion'
'UnixProcessUnixFileLockingTestCase>>#testFailRegionLockOnLockedFile'
'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite01'
'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite02'
'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite03'
'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite04'
'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite05'
'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite06'
'UnixProcessUnixFileLockingTestCase>>#testLockRegionForRead01'
'UnixProcessUnixFileLockingTestCase>>#testLockRegionForRead02'
'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite01'
'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite02'
'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite03'
'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite04'
'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite05'
'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite06'
'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite07'
'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite08'
'UnixProcessUnixFileLockingTestCase>>#testNoFailLockOnAdjacentLockedRegions'
'UnixProcessUnixFileLockingTestCase>>#testNoFailLockOnDifferentLockedRegion'
'UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses01'
'UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses02'
'UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses03'
'UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses04'
'UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses05'
'UnixProcessWin32FileLockingTestCase>>#testFailFileLockOnLockedFile'
'UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedOverlappedRegion'
'UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedRegion'
'UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedSupersetRegion'
'UnixProcessWin32FileLockingTestCase>>#testFailRegionLockOnLockedFile'
'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite01'
'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite02'
'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite03'
'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite04'
'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite05'
'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite06'
'UnixProcessWin32FileLockingTestCase>>#testLockRegionForRead01'
'UnixProcessWin32FileLockingTestCase>>#testLockRegionForRead02'
'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite01'
'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite02'
'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite03'
'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite04'
'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite05'
'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite06'
'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite07'
'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite08'
'UnixProcessWin32FileLockingTestCase>>#testNoFailLockOnAdjacentLockedRegions'
'UnixProcessWin32FileLockingTestCase>>#testNoFailLockOnDifferentLockedRegion')

#166348

From: Tim Felgentreff <tim@...>
Date: Wed May 2, 2012 6:45 pm
Subject: RE: [squeak-dev] AioPlugin and SqueakSSL plugin included in Cocoa(please test)

tim@...

I would like to be able to run tests on my dev machine, too - if those involve OpenID auth via SSL or what-have-you, I need SSL there, too.

From: Chris Cunnington
Sent: 02/05/2012 18:07
To: sq >> The general-purpose Squeak developers list
Subject: [squeak-dev] AioPlugin and SqueakSSL plugin included in Cocoa(please test)

> I added AioPlugin and SqueakSSL plugins in Cocoa builds.

At the risk of seeming more obtuse than I usually am, why would I want SSL in an Apple VM unless I'm running an Apple server, which almost nobody does? SSL in a Linux VM, yea, OK, I get that. Does my desktop image running on my Mac need SSL for something?

Chris

Andy Dufresne: How can you be so obtuse?
Warden Samuel Norton: What? What did you call me?
Andy Dufresne: Obtuse. Is it deliberate?
Warden Samuel Norton: Son, you're forgetting yourself.
Andy Dufresne: The country club will have his old time cards. Records, W-2s with his name on them. Sir, if I ever get out, I'd never mention what happens here. I'd be just as indictable as you for laundering that money.

Reply | Messages in this Topic (1)

#166349

From: Casey ransberger <casey.obrien.r@...>
Date: Wed May 2, 2012 7:33 pm
Subject: Re: [squeak-dev] [Cuis - ANN] Blowfish for Cuis 4.0

casey.obrien.r@...

This is cool!

On May 1, 2012, at 7:20 AM, Germán Arduino <garduino@...> wrote:

Hi Guys:

I would ilke to announce the port for Cuis of Blowfish (the implementation of Paul de Bruicker).

It's available on https://github.com/garduino/Cuis-Cryptography

Also you will find the basic SystemHashing ported from Pharo 1.4.

To install:

1. Take a Cuis 4.0 image.
2. Install all the updates (#1270 at the moment).

3. Clone my GitHub repo on your machine.
4. Surf the local repo with the Cuis FileList.
5. Select the package, press "install package" and voila!

Cheers.

--
============================================
Germán S. Arduino <gsa @ arsol.net> Twitter: garduino
Arduino Software http://www.arduinosoftware.com
PasswordsPro http://www.passwordspro.com
greensecure.blogspot.com germanarduino.blogpost.com
============================================

#166350

From: Paul DeBruicker <pdebruic@...>
Date: Wed May 2, 2012 8:31 pm
Subject: Re: [squeak-dev] [Cuis - ANN] Blowfish for Cuis 4.0

pdebruic@...

I'm glad you find this useful enough to port.

One of the things I'm confused about is in the 'Blowfish.pck' file on
github on line 42 the instance variable 'rounds' has a list of classes
that follow it.  Most of those classes have nothing to do with the
Blowfish package and are from things like Chronos or Didier Bisset's
numerical algorithms both of which aren't dependencies..

Is there something I've done to pollute the package that I could clean
up? Is it pretty normal for that type of thing to happen?

Thanks again

Paul

On 05/01/2012 07:20 AM, Germ�n Arduino wrote:
> Hi Guys:
>
> I would ilke to announce the port for Cuis of Blowfish (the
> implementation of Paul de Bruicker).
>
> It's available on https://github.com/garduino/Cuis-Cryptography
>
> Also you will find the basic SystemHashing ported from Pharo 1.4.
>
> To install:
>
> 1. Take a Cuis 4.0 image.
> 2. Install all the updates (#1270 at the moment).
> 3. Clone my GitHub repo on your machine.
> 4. Surf the local repo with the Cuis FileList.
> 5. Select the package, press "install package" and voila!
>
>
> Cheers.
>
>
> --
> ============================================
> Germ�n S. Arduino <gsa @ arsol.net <http://arsol.net>>   Twitter: garduino
> Arduino Software http://www.arduinosoftware.com
> PasswordsPro http://www.passwordspro.com
> greensecure.blogspot.com <http://greensecure.blogspot.com>
> germanarduino.blogpost.com <http://germanarduino.blogpost.com>
> ============================================
>
>
>
>

#166351

From: "Juan Vuletich (mail lists)" <juanlists@...>
Date: Wed May 2, 2012 8:38 pm
Subject: Re: [squeak-dev] [Cuis - ANN] Blowfish for Cuis 4.0

juanlists@...

Hi Paul,

Quoting Paul DeBruicker <pdebruic@...>:

> I'm glad you find this useful enough to port.
>
> One of the things I'm confused about is in the 'Blowfish.pck' file
> on github on line 42 the instance variable 'rounds' has a list of
> classes that follow it.  Most of those classes have nothing to do
> with the Blowfish package and are from things like Chronos or Didier
> Bisset's numerical algorithms both of which aren't dependencies..
>
> Is there something I've done to pollute the package that I could
> clean up? Is it pretty normal for that type of thing to happen?
>
> Thanks again
>
> Paul

That�s the class comment for class Blowfish. It came with it.

Cheers,
Juan Vuletich

#166352

From: Germ�n Arduino <garduino@...>
Date: Wed May 2, 2012 9:54 pm
Subject: Re: [squeak-dev] [Cuis - ANN] Blowfish for Cuis 4.0

garduino@...

Thanks Casey and Paul.

I saw that Juan already responded to your question Paul. I will check as soon as I can to verify such content.

Thanks to you for the Smalltalk code for Blowfish.

Cheers!

2012/5/2 Juan Vuletich (mail lists) <juanlists@...>

Hi Paul,

Quoting Paul DeBruicker <pdebruic@...>:

I'm glad you find this useful enough to port.

One of the things I'm confused about is in the 'Blowfish.pck' file on github on line 42 the instance variable 'rounds' has a list of classes that follow it. �Most of those classes have nothing to do with the Blowfish package and are from things like Chronos or Didier Bisset's numerical algorithms both of which aren't dependencies..

Is there something I've done to pollute the package that I could clean up? Is it pretty normal for that type of thing to happen?

Thanks again

Paul

That�s the class comment for class Blowfish. It came with it.

Cheers,
Juan Vuletich

--
============================================
Germ�n S. Arduino� <gsa @ arsol.net>�� Twitter: garduino
Arduino Software �http://www.arduinosoftware.com
PasswordsPro� http://www.passwordspro.com

greensecure.blogspot.com germanarduino.blogpost.com
============================================

#166353

From: Yoshiki Ohshima <Yoshiki.Ohshima@...>
Date: Thu May 3, 2012 4:39 am
Subject: Re: [squeak-dev] Decompilation problem

Yoshiki.Ohshima@...

At Thu, 12 Apr 2012 18:08:01 -0700,
Eliot Miranda wrote:
>
>         So has OMeta patched some old bug in the decompiler which is now
obsoleted by some other fix?
>
>     The difference appears to be that the OMeta compiler
answers�'(t)[(t)[(t)]]' for the�schematicTempNamesString. The regular compiler
answers 't'. This trips the Decompiler over.
>
> Bingo. �OMeta looks to be computing the schematic temps for the method before
inlining and closure analysis, in that the ifTrue: argument is an actual block
according to that string. �Good
> catch!

I understand what you mean, but I still cannot see how this can
happen.  What I do is to load OMeta2 from
http://www.squeaksource.com/OMeta.html, go to a method like
OMeta2Examples>>fact in the broser and and press the "decomple"
button.  (The actual schematicTempNamesString is different and you get
different symptom, but it seems to be stemming from the same problem.)

In the current implementation it comes down to something like:

(Parser new parse:  'fact
	 | m n |
	 ^ self ometaOr: {[true
			 ifTrue: [true
					 ifTrue: [self apply: #exactly withArgs: {0}].
				 self ometaOr: {[true
						 ifTrue: [1]]}]]. [true
			 ifTrue: [true
					 ifTrue: [n := self apply: #anything].
				 self ometaOr: {[true
						 ifTrue: [m := self apply: #fact withArgs: {n - 1}.
							 n * m]]}]]}' readStream class: Object noPattern: false context: nil
notifying: nil ifFail: []) generate: CompiledMethodTrailer defaultMethodTrailer;
										 schematicTempNamesString.

and I get "'(m n)[[]][(m n)[(m n)]]'" as its results.  Is there a call
to make other than parse:class:noPattern:context:notifying:ifFail:?

-- Yoshiki

Reply | Messages in this Topic (8)

#166354

From: Casimiro de Almeida Barreto <casimiro.barreto@...>
Date: Thu May 3, 2012 3:13 pm
Subject: Re: [squeak-dev] Squeak Oversight Board minutes � 5/01/12

casimiro.barreto@...

On 02-05-2012 09:57, Chris Cunnington wrote:
> Squeak Oversight Board minutes � 5/01/12
>
> Attending: Chris Muller, Colin Putney, Levente Uzonyi, Chris
> Cunnington, Bert Freudenberg, Craig Latta
>
> - the SOB meeting time is being changed tentatively to 1st and 3rd
> Mondays noon in Los Angeles, so the next meeting is at May 7, 12pm
> L.A., Calif. time
>
> - Colin is talking to Joyent [1] in Vancouver about hosting. They are
> a large supporter of node.js
>
> - Colin is compiling Cog for Illumos (a branch of Solaris) [2]
It would be interesting to have a x86_64 version of Cog running in all
supported platforms (windowze, OS X, Linux, iOS, etc). i686 architecture
is not well supported in newer versions of many OSes, particularly
mixing i686 and x86_64 in Linux is kind of hell. Besides, it makes no
sense to have only the old 32bit image and it would be good to have a
64bit one (addressing, etc) though it would demand changes in VMs. The
last 64bit image I was able to mine dates from 2010.
> - It was agreed that the a transition from our current server to a new
> server is required, as the current server hardware cannot run Cog
> (it's an old AMD Athlon without SSE2)
>
> - We discussed Squeak�s market position. Ideas around it being a
> �flexible platform� and how it gives a user �complete control� were
> emphasized. Squeak has been the point of departure for many innovative
> projects: RoarVM, Scratch, Croquet, Pharo, Etoys
Market position depends on lots of things. I guess that although more
than 10 years old, squeak is not mature enough for market. Important
things like defining what is central to distribution image and what is
not, establishing standards for things that are central to distribution
image, documenting things, enhancing interfaces with OSes, etc.
>
> - Craig�s plans for Spoon in the coming year include porting the Naiad
> module system to Squeak and other Smalltalks; and, making example
> modules from existing Squeak code as a demonstration for other people
> to get started
>
> - The SOB is exploring the idea of having a Squeak event in North
> American sometime in its tenure this year.
>
> - There are plans to contact the SqueakFest [3] organizers to include
> a track of programming for other kinds of Squeak projects than the
> educational
>
> [1] http://www.joyent.com
> [2] http://wiki.illumos.org/display/illumos/illumos+Home
> [3] http://squeakland.org/squeakfest/about/
>
> .
>

#166355

From: commits@...
Date: Thu May 3, 2012 4:16 pm
Subject: [squeak-dev] The Trunk: System-eem.484.mcz

commits@...

Eliot Miranda uploaded a new version of System to project The Trunk:
http://source.squeak.org/trunk/System-eem.484.mcz

==================== Summary ====================

Name: System-eem.484
Author: eem
Time: 3 May 2012, 9:15:17.73 am
UUID: 22d19428-0bee-46fc-b869-420d7994d06a
Ancestors: System-eem.483

Stricter methodsWithUnboundGlobals

=============== Diff against System-eem.483 ===============

Item was changed:
   ----- Method: SystemNavigation>>methodsWithUnboundGlobals (in category
'query') -----
   methodsWithUnboundGlobals
  	 "Get all methods that use undeclared global objects that are not listed in
Undeclared. For a clean image the result should be empty."

  	 "SystemNavigation new methodsWithUnboundGlobals"

  	 ^self allSelect:
  		 [:m|
  		 m literals anySatisfy:
  			 [:l|
  			 l isVariableBinding
  			 and: [l key isSymbol "avoid class-side methodClass literals"
+ 		 and: [(m methodClass bindingOf: l key)
+ 				 ifNil: [(Undeclared associationAt: l key ifAbsent: []) ~~ l]
+ 				 ifNotNil: [:b| b ~~ l]]]]]!
- 		 and: [(m methodClass bindingOf: l key) isNil
- 		 and: [(Undeclared associationAt: l key ifAbsent: []) ~~ l]]]]]!

Reply | Messages in this Topic (1)

#166356

From: commits@...
Date: Thu May 3, 2012 11:55 pm
Subject: [squeak-dev] Daily Commit Log

commits@...

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours:

http://lists.squeakfoundation.org/pipermail/packages/2012-May/005315.html

Name: System-eem.484
Ancestors: System-eem.483

Stricter methodsWithUnboundGlobals

=============================================

Reply | Messages in this Topic (832)

#166357

From: Casey Ransberger <casey.obrien.r@...>
Date: Fri May 4, 2012 2:50 am
Subject: Re: [squeak-dev] Squeak Oversight Board minutes – 5/01/12

casey.obrien.r@...

Inline and abridged.

On May 3, 2012, at 8:13 AM, Casimiro de Almeida Barreto
<casimiro.barreto@...> wrote:

> On 02-05-2012 09:57, Chris Cunnington wrote:
>> Squeak Oversight Board minutes – 5/01/12
>>
>> (big snip)
> It would be interesting to have a x86_64 version of Cog running in all
> supported platforms (windowze, OS X, Linux, iOS, etc). i686 architecture
> is not well supported in newer versions of many OSes, particularly
> mixing i686 and x86_64 in Linux is kind of hell. Besides, it makes no
> sense to have only the old 32bit image and it would be good to have a
> 64bit one (addressing, etc) though it would demand changes in VMs. The
> last 64bit image I was able to mine dates from 2010.

It would; I think it's worth noting, though, that there's probably a pile of
work underneath making it happen. There are also other considerations, like what
you want out of a 64-bit Cog. Do you want a huge image or to add 64 bit integers
as efficiently as possible? What's the goal?

The goal will tell us things. Should we go back to a vtable or keep on keeping
on with direct pointers?

Etc...

>> - It was agreed that the a transition from our current server to a new
>> server is required, as the current server hardware cannot run Cog
>> (it's an old AMD Athlon without SSE2)
>>
>> - We discussed Squeak’s market position. Ideas around it being a
>> “flexible platform” and how it gives a user “complete control” were
>> emphasized. Squeak has been the point of departure for many innovative
>> projects: RoarVM, Scratch, Croquet, Pharo, Etoys
> Market position depends on lots of things. I guess that although more
> than 10 years old, squeak is not mature enough for market. Important
> things like defining what is central to distribution image and what is
> not, establishing standards for things that are central to distribution
> image, documenting things, enhancing interfaces with OSes, etc.

Disagree. It's a hell of a lot more mature than Ruby, and I use that stuff all
the time at work. Squeak isn't immature, it's just alien. People don't generally
want to unlearn what they've learned. The challenges around marketing, IMHO, are
mostly cultural.

>> (big snip)

#166358

From: Stéphane Rollandin <lecteur@...>
Date: Fri May 4, 2012 7:18 am
Subject: Re: [squeak-dev] Squeak Oversight Board minutes – 5/01/12

lecteur@...

> Squeak isn't immature, it's just alien.

Exactly !


Stef

#166359

From: Nicolas Cellier <nicolas.cellier.aka.nice@...>
Date: Fri May 4, 2012 7:55 am
Subject: Re: [squeak-dev] Squeak Oversight Board minutes � 5/01/12

nicolas.cellier.aka.nice@...

2012/5/4 Casey Ransberger <casey.obrien.r@...>:
> Inline and abridged.
>
> On May 3, 2012, at 8:13 AM, Casimiro de Almeida Barreto
<casimiro.barreto@...> wrote:
>
>> On 02-05-2012 09:57, Chris Cunnington wrote:
>>> Squeak Oversight Board minutes � 5/01/12
>>>
>>> (big snip)
>> It would be interesting to have a x86_64 version of Cog running in all
>> supported platforms (windowze, OS X, Linux, iOS, etc). i686 architecture
>> is not well supported in newer versions of many OSes, particularly
>> mixing i686 and x86_64 in Linux is kind of hell. Besides, it makes no
>> sense to have only the old 32bit image and it would be good to have a
>> 64bit one (addressing, etc) though it would demand changes in VMs. The
>> last 64bit image I was able to mine dates from 2010.
>
> It would; I think it's worth noting, though, that there's probably a pile of
work underneath making it happen. There are also other considerations, like what
you want out of a 64-bit Cog. Do you want a huge image or to add 64 bit integers
as efficiently as possible? What's the goal?
>

IMHO, that's not only a question of handling huge image, there might
be an advantage for some applications with more speed-efficient object
format like for example:

1) immediate double values (like VW SmallDouble)
2) immediate characters
3) 32 bit integers, signed or unsigned - that would simplify a lot of
handlings, and greatly accelerate LargeInteger arithmetic which is
still based on 8bit operations on our 64 bits machines !

Nicolas

> The goal will tell us things. Should we go back to a vtable or keep on keeping
on with direct pointers?
>
> Etc...
>
>>> - It was agreed that the a transition from our current server to a new
>>> server is required, as the current server hardware cannot run Cog
>>> (it's an old AMD Athlon without SSE2)
>>>
>>> - We discussed Squeak�s market position. Ideas around it being a
>>> �flexible platform� and how it gives a user �complete control� were
>>> emphasized. Squeak has been the point of departure for many innovative
>>> projects: RoarVM, Scratch, Croquet, Pharo, Etoys
>> Market position depends on lots of things. I guess that although more
>> than 10 years old, squeak is not mature enough for market. Important
>> things like defining what is central to distribution image and what is
>> not, establishing standards for things that are central to distribution
>> image, documenting things, enhancing interfaces with OSes, etc.
>
> Disagree. It's a hell of a lot more mature than Ruby, and I use that stuff all
the time at work. Squeak isn't immature, it's just alien. People don't generally
want to unlearn what they've learned. The challenges around marketing, IMHO, are
mostly cultural.
>
>>> (big snip)
>

#166360

From: Casey Ransberger <casey.obrien.r@...>
Date: Fri May 4, 2012 8:16 am
Subject: Re: [squeak-dev] Squeak Oversight Board minutes – 5/01/12

casey.obrien.r@...

Below.

On May 4, 2012, at 12:55 AM, Nicolas Cellier
<nicolas.cellier.aka.nice@...> wrote:

(huge snip, context is in the rest of the thread)

> IMHO, that's not only a question of handling huge image, there might
> be an advantage for some applications with more speed-efficient object
> format like for example:
>
> 1) immediate double values (like VW SmallDouble)
> 2) immediate characters
> 3) 32 bit integers, signed or unsigned - that would simplify a lot of
> handlings, and greatly accelerate LargeInteger arithmetic which is
> still based on 8bit operations on our 64 bits machines !
>
> Nicolas

Mr. Cellier, a.k.a. "nice," is supporting my point flawlessly. I threw out a
couple of reasons to design in particular directions as a way to illustrate that
the road to 64-bit is not well defined for us yet, I did so to point out that
just bitwidth isn't the only important consideration, and he's pointed out that
even the arguments I presented as examples *grossly* underthink the issues
involved.

To be clear: I'm quite passionate about seeing a 64-bit Cog walk, and I think
it's something to strive for, but there are some wonderful people using this VM
with different goals, and perhaps unfortunately, learning what we all need from
a 64-bit VM is likely to be a longish conversation.

In any event, though, #doIt! Make it work, if you want it, and then the rest of
the world will be quite out of your way while you're using what you've made. At
least in Squeak, we can do stuff like that.

CC Eliot because it's his baby and I don't even know what I'm talking about:) At
least, he can probably speak to the challenges around 64-bit support as well as
absolutely anyone else around.

Casey

#166361

From: commits@...
Date: Fri May 4, 2012 8:52 am
Subject: [squeak-dev] The Trunk: Kernel-nice.685.mcz

commits@...

Nicolas Cellier uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-nice.685.mcz

==================== Summary ====================

Name: Kernel-nice.685
Author: nice
Time: 4 May 2012, 10:51:32.635 am
UUID: 2febaac6-3ff5-3640-abfd-068dce4f0a2b
Ancestors: Kernel-eem.684

Rename Number class>>#readSqueakSyntaxFrom: into #readSmalltalkSyntaxFrom:

This is to provide a common API across dialects for external packages since both
VW7.x and Pharo2.0 have #readSmalltalkSyntaxFrom:

Note that Number syntax may vary slightly across dialects and
#readSmalltalkSyntaxFrom: is to be understood "in local dialect"...

#readSqueakSyntaxFrom: was quite recent and not used in trunk, so I removed
rather than deprecate. If you don't agree, raise your voice.

=============== Diff against Kernel-eem.684 ===============

Item was added:
+ ----- Method: Number class>>readSmalltalkSyntaxFrom: (in category 'instance
creation') -----
+ readSmalltalkSyntaxFrom: stringOrStream
+  "Answer a number as described on aStream.  The number may
+  be any accepted Smalltalk literal Number format.
+  It can include a leading radix specification, as in 16rFADE.
+  It can as well be NaN, Infinity or -Infinity for conveniency.
+  If stringOrStream does not start with a valid number description, fail."
+
+  ^(SqNumberParser on: stringOrStream) nextNumber!

Item was removed:
- ----- Method: Number class>>readSqueakSyntaxFrom: (in category 'instance
creation') -----
- readSqueakSyntaxFrom: stringOrStream
-  "Answer a number as described on aStream.  The number may
-  be any accepted Smalltalk literal Number format.
-  It can include a leading radix specification, as in 16rFADE.
-  It can as well be NaN, Infinity or -Infinity for conveniency.
-  If stringOrStream does not start with a valid number description, fail."
-
-  ^(SqNumberParser on: stringOrStream) nextNumber!

Reply | Messages in this Topic (1)

#166362

From: Bert Freudenberg <bert@...>
Date: Fri May 4, 2012 9:59 am
Subject: [squeak-dev] 64 bits (was: Squeak Oversight Board minutes � 5/01/12)

bert@...

On 04.05.2012, at 10:16, Casey Ransberger wrote:

> Below.
>
> On May 4, 2012, at 12:55 AM, Nicolas Cellier
<nicolas.cellier.aka.nice@...> wrote:
>
> (huge snip, context is in the rest of the thread)
>
>> IMHO, that's not only a question of handling huge image, there might
>> be an advantage for some applications with more speed-efficient object
>> format like for example:
>>
>> 1) immediate double values (like VW SmallDouble)
>> 2) immediate characters
>> 3) 32 bit integers, signed or unsigned - that would simplify a lot of
>> handlings, and greatly accelerate LargeInteger arithmetic which is
>> still based on 8bit operations on our 64 bits machines !
>>
>> Nicolas
>
> Mr. Cellier, a.k.a. "nice," is supporting my point flawlessly. I threw out a
couple of reasons to design in particular directions as a way to illustrate that
the road to 64-bit is not well defined for us yet, I did so to point out that
just bitwidth isn't the only important consideration, and he's pointed out that
even the arguments I presented as examples *grossly* underthink the issues
involved.
>
> To be clear: I'm quite passionate about seeing a 64-bit Cog walk, and I think
it's something to strive for, but there are some wonderful people using this VM
with different goals, and perhaps unfortunately, learning what we all need from
a 64-bit VM is likely to be a longish conversation.
>
> In any event, though, #doIt! Make it work, if you want it, and then the rest
of the world will be quite out of your way while you're using what you've made.
At least in Squeak, we can do stuff like that.
>
> CC Eliot because it's his baby and I don't even know what I'm talking about:)
At least, he can probably speak to the challenges around 64-bit support as well
as absolutely anyone else around.
>
>
> Casey


IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit machine.
Running 64 bit images would be nice, too, but the problem most users run into
right now is that they just cannot easily run their current image on that shiny
new box.

- Bert -

#166363

From: Douglas Brebner <squeaklists@...>
Date: Fri May 4, 2012 11:23 am
Subject: Re: [squeak-dev] 64 bits

squeaklists@...

On 04/05/2012 10:59, Bert Freudenberg wrote:

On 04.05.2012, at 10:16, Casey Ransberger wrote:

Below.
On May 4, 2012, at 12:55 AM, Nicolas Cellier <nicolas.cellier.aka.nice@...> wrote:
(huge snip, context is in the rest of the thread)

IMHO, that's not only a question of handling huge image, there might
be an advantage for some applications with more speed-efficient object
format like for example:
1) immediate double values (like VW SmallDouble)
2) immediate characters
3) 32 bit integers, signed or unsigned - that would simplify a lot of
handlings, and greatly accelerate LargeInteger arithmetic which is
still based on 8bit operations on our 64 bits machines !
Nicolas

Mr. Cellier, a.k.a. "nice," is supporting my point flawlessly. I threw out a couple of reasons to design in particular directions as a way to illustrate that the road to 64-bit is not well defined for us yet, I did so to point out that just bitwidth isn't the only important consideration, and he's pointed out that even the arguments I presented as examples *grossly* underthink the issues involved. To be clear: I'm quite passionate about seeing a 64-bit Cog walk, and I think it's something to strive for, but there are some wonderful people using this VM with different goals, and perhaps unfortunately, learning what we all need from a 64-bit VM is likely to be a longish conversation. In any event, though, #doIt! Make it work, if you want it, and then the rest of the world will be quite out of your way while you're using what you've made. At least in Squeak, we can do stuff like that. CC Eliot because it's his baby and I don't even know what I'm talking about:) At least, he can probably speak to the challenges around 64-bit support as well as absolutely anyone else around.
Casey

IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit machine. Running 64 bit images would be nice, too, but the problem most users run into right now is that they just cannot easily run their current image on that shiny new box.

This brings up a problem I've noticed happen occasionally: there are two different meanings of "64bit VM" and people keep confusing them.

1. A VM that runs on 64bit hardware (with 32 or 64bit images)
2. A VM that runs a 64bit image (on 32 or 64bit hardware)

While there is some overlap (e.g. 32bit image talking to 64bit plugins), we should not confuse them.

#166364

From: Bert Freudenberg <bert@...>
Date: Fri May 4, 2012 12:09 pm
Subject: Re: [squeak-dev] 64 bits

bert@...

On 04.05.2012, at 13:23, Douglas Brebner wrote:

> On 04/05/2012 10:59, Bert Freudenberg wrote:
>> IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit
machine. Running 64 bit images would be nice, too, but the problem most users
run into right now is that they just cannot easily run their current image on
that shiny new box.
>>
> This brings up a problem I've noticed happen occasionally: there are two
different meanings of "64bit VM" and people keep confusing them.
>
> 1. A VM that runs on 64bit hardware (with 32 or 64bit images)
> 2. A VM that runs a 64bit image (on 32 or 64bit hardware)
>
> While there is some overlap (e.g. 32bit image talking to 64bit plugins), we
should not confuse them.

Well explained here:

	 http://squeakvm.org/squeak64/faq.html

- Bert -