I tend to switch back and forth between a variety of VMs and images (Spur, Cog,
interpreter VM etc). Lately I have been doing my updates from a format 68002
64-bit image. Just curious, is anybody else out there using a 64-bit image on
a regular basis and keeping it updated from the trunk development stream?
Dave
...at http://www.mirandabanda.org/files/Cog/VM/VM.r3058/.
CogVM binaries as per VMMaker.oscog-eem.842/r3058
Spur:
Provide unpinObject: for InterpreterProxy.
Fix initialization of the heap-resident remembered set added by
VMMaker.oscog-eem.827. It must be created /after/ old space is initialized.
Fix two become bugs surfaced when adding/removing inst vars to/from
Association,
Binding et al. First, the class table must be scanned to ensure there are
no
forwarders to classes (much cheaper than the full hierarchy walk to follow
method dictionaries etc that was done). Second, machine code methods that
gain
a new reference through become must get added to the youngReferrers. Add a
new
become effect flag, OldBecameNew that captures this and respond to it in
CoInterpreter>>postBecomeAction: by adding all methods to youngReferrers so
that on the next scavenge all will be made right.
Fix GC of machine code, which must follow forwarders when doing
markAndTraceLiteral: and again add to youngReferrers if following
gains a new ref. Refactoring of markAndTraceLiteral: into
markAndTraceLiteral:in:at: et al required.
Fix assert in addFreeSubTree:.
General:
Support the alternate bytecode set header in all VMs to ease testing of
multiple bytecode sets. This means methods with the sign bit set have
no primitive field and a larger num literals field, but no more.
Fix longPrintOop: (actually printOopShortInner:) for
global variable printing in face of new Environments.
Cogit:
Clean up adding to the youngReferrers by providing ensureInYoungReferrers:.
Since there always is room on youngReferrers, nuke roomOnYoungReferrersList,
canLinkToYoungClasses and caller code, simplifying ceSend:super:to:numArgs:
etc.
Fix assert in followForwardedLiteralsIn:
General:
Change the scanning for initial nils scheme in the
StackToRegisterMappingCogit
to answer the number of push nils in a bytecode, instead of whether the
bytecode is a push nil. Refactor genReturnTopFromBlock into genBlockReturn.
These changes accomodate Sista.
Rationalize the length functions, deleting byteLengthOf:,
fetchLong32LengthOf:
& fetchWordLengthOf: and providing numBytesOf:, num16BitUnitsOf:,
num32BitUnitsOf:, num64BitUnitsOf: and numBytesOf:.
Provide fetch/storeShort16:ofObject:[withValue:] and
fetch/storeLong64:ofObject:[withValue:].
--
best,
Eliot
Dear fellow Squeakers,
I continued my quest to create a current clean 4.6 trunk imge and still run into problems.
I am on OS X 10.9.4. I use Eliot's latest Cog.app and the 4.5 release image (Squeak4.5-13680.image) from the FTP server. See here [1] for the bash commands I use to set up my starting point.
Then I execute the following script in a workspace:
MCMcmUpdater
defaultUpdateURL: 'http://source.squeak.org/trunk';
updateFromServer.
During processing of update-eem.287.mcm a popup menu appears saying that the Squeak4.5-13680.changes file does not exist. This is incorrect because the file exists. When I choose Debug I get FileDoesNotExistException. See the attached PNG and SqueakDebug.log.
I would be interested if others run into the same problem.
Cheers,
Bernhard
[1]
mkdir trunk
cd trunk
curl -O http://www.mirandabanda.org/files/Cog/VM/VM.r3063/Cog.app-14.32.3063.tgz
gunzip -c Cog.app-14.32.3063.tgz | tar xopf - && rm Cog.app-14.32.3063.tgz
curl -O ftp://ftp.squeak.org/4.5/SqueakV41.sources.zip
unzip SqueakV41.sources.zip && rm SqueakV41.sources.zip
curl -O ftp://ftp.squeak.org/4.5/Squeak4.5-13680.zip
unzip Squeak4.5-13680.zip && rm Squeak4.5-13680.zip
./Cog.app/Contents/MacOS/Squeak Squeak4.5-13680.image
Hi guys, did anyone happen to notice that RIGHT-CLICK DOESN'T WORK in
Windows on our Squeak-4.5 release download?
http://webcache.googleusercontent.com/search?q=cache:xIgjzkwaWr4J:stackover…
Verified. HTF did this get past our testing? Was it related to a
last-minute inclusion of the CogVM?
Whatever -- need to put out an update. Some acquaintences of mine
wanting to learn Squeak, following Lawson English instructional videos
except they couldn't get the right-click menu, they sent me the link
above indicating others having the same issue. Not a good first
impression!
1) What is the proper fix? It seems the
3ButtonMouse=0
in the "squeak.ini" file, it should be 1 right? Changing it seems to
clear up the issue in Windows, but so does "swapMouseButtons" in the
image, but flipping that would foul it up for Linux so I'm thinking
the .ini file.
2) Did we do something related to "signing" for Mac and so I suppose
flipping that will require the new All-In-One to be resigned to work
on Mac (?). I know nothing about Mac, please advise.
3) If we have to resign anyway, 4.5 has had a few updates taking it to
13687 instead of 13680 (current 4.5 download). So if we have to
resign anyway, should we go ahead and deliver this latest image too?
4) If we delivering a new image, maybe we should call it 4.5.1?
As release manager, I'm embarassed, and inclined to make this right.
Please help me think this through and with the Mac stuff..
http://codeconnect.io/ shows someone editing code displayed on a
function-by-function basis (sound familiar), with senders-of the
currently displayed function/method automatically displayed in a
column to the right.
That seems rather familiar, and a semi-straightforward thing to
implement using our current browsers, right?
frank
One other thing that I found out is that the trunk update from Squeak4.5-13680.image seems to create corrupt files in the package-cache. I use the following batch script to verify:
#!/bin/bash
cd trunk/package-cache
for f in *.mcd *.mcz
do
unzip -t $f | grep "No errors"
done
Most but not all of the files in the package-cache seem to be corrupt.
I would be interested if others see that also.
Cheers,
Bernhard
It's a subject I've thought a lot about. Somewhere about halfway through
it, there's a little simulation. It made me think a bit of the classic
EToys experiment with epidemiology (the bit with all the green bouncing
atoms turning red when they bump into red ones, starting with a red one and
a bunch of green ones.)
As I looked at it, I thought: boy, that sure looks a lot like it was done
using Squeak. And a slightly earlier version, too, to my eye. Something
about the font and the absence of very much left padding in the text box
seemed to smack of Squeak.
Anyway, it could be worth watching generally, but really I'm just curious,
and if there's a single human quality which I can identify in myself that
I'm genuinely proud of, it's the boundless curiosity. Does anyone here know
the author of this talk? The demonstration could have been implemented with
anything, but if it was Squeak, it would be a hell of a lot of fun to
vivisect the thing. Okay, lousy metaphor. Hopefully people can tell what
I'm trying to say though; obviously I'm not the sort that cuts a mouse open
while it's still alive (though I have a terrible habit of saying things
that are likely to greatly upset it, so much so that I'll feel horrible
about myself later, even if it felt fantastic to say at the time.)
I think this little TED talk really speaks -- in a sort of subtext -- to
the liberating power of simulation. So to Squeak or not to Squeak, either
way it's interesting and (I think) relevant to at least part of the
community.
Thanks again for the perspective, folks,
C
http://www.ted.com/talks/daniel_goldstein_the_battle_between_your_present_a…
I will present the DCI paradigm (Data, Context, Interaction) at ESUG
Thursday 12:00. The presentation rests on a live demo of a Squeak image.
The image is posted on
http://fulloo.info/Downloads/BabyIDE-3a.zip
/Working with objects in computer and mind//
// Master the runtime!/
--Trygve
--
Trygve Reenskaug mailto: trygver(a)ifi.uio.no
Morgedalsvn. 5A http://folk.uio.no/trygver/http://fulloo.info/
N-0378 Oslo http://fullOO.info
Norway Mobile: (+47) 468 58 625
Just from a API-structure POV, shouldn't the user-API's call the
lower-level "basic" API's instead of vice-versa?
IOW, "basic..." methods are meant for low-level implementations while
the non-basic are meant for user-access. Low-level implementations
calling the higher-level user methods smells..
On Fri, Aug 29, 2014 at 9:39 AM, <commits(a)source.squeak.org> wrote:
> A new version of Collections was added to project The Inbox:
> http://source.squeak.org/inbox/Collections-cbc.581.mcz
>
> ==================== Summary ====================
>
> Name: Collections-cbc.581
> Author: cbc
> Time: 29 August 2014, 7:39:32.599 am
> UUID: a38b6f89-e4f2-7b4b-99d3-eeafa9c35445
> Ancestors: Collections-nice.580
>
> Fix #basicUpTo: to call #upTo: instead of #next:
>
> =============== Diff against Collections-nice.580 ===============
>
> Item was changed:
> ----- Method: PositionableStream>>basicUpTo: (in category 'accessing - multibyte support') -----
> basicUpTo: anObject
>
> + ^self upTo: anObject
> - ^self next: anObject
> !
>
>