I rolled back to the previous version (Actually I uploaded the one from 1150 which was the last correct 64bit version). Not that I really wanted to commit anything in the first place, lousy (yet useful) gui tools really should have a preference to allow you to confirm svn cmds before execution.

On Apr 13, 2005, at 2:06 PM, Ian Piumarta wrote:

You roll things back with the 'merge' command. The doc explains how.

BTW: if anyone rolls back sq.h they'll immediately collect the 'fix all the bugs in it' token.

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

So let's just drop the no longer needed macro.

Agreed.

Cheers, - Andreas

Tim Rowledge wrote:

In message eb81540cc952c77de4f5dce8dac86200@inria.fr Ian Piumarta ian.piumarta@inria.fr wrote:

...

is being checked, and one is deliberate to avoid a bug wherein dispatchFunctionPointer cannot be simultaneously declared a macro in sq.h and a function from within generated sources (the compiler explodes when inlining is disabled).

So let's just drop the no longer needed macro. And yes, anyone using that edition of sq.h with older generated sources will get bitten - so what. There should be a pickled set of non-generated files tagged (or branched or whatever) to be used with the previous release. As we've said before, the intention is to try to make code stay compatible but no promises.

tim

Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Oxymorons: Terribly pleased

I looked at this a few months back, since each change is numbered you just wander thru the log picking out where your versions were commited. For example for the mac I've noted: 3.2.1b6 is 80 3.2.2 is 179 3.2.3 is 187 3.2.4 is 211 3.2.5b8 is 268 3.2.6b8 is 308 3.2.7b7 is 429 3.2.8b9 is 482 3.4.0b2 is 498 3.5.0b4 is 545 3.5.1b5 is 595 3.5.2b6 is 771 (issues with other update?) 3.6.0b2b is 785 3.6.1b5 is 798 3.6.2b3 is 805 (not shipped)

With this in theory you can create a branch for your vm version by copying the main trunk upto the particular version number in question to a branch folder. Can't say I know what the proper svn cmd would be tho. I have local pickled versions and noted say for 3.5.2b6 I managed to get a change from 3.6.0 into the mix without out actually committing it as a 3.5.2b6 flavor.

If someone wants to say what the svn cmds would be I'll consider as time permits doing a copy and validation.

Lastly I also understand you can update the branch/copy to tweak things a bit to reflect mistakes made in updates years ago. (such as correctly versioning 3.5.2b6)

On Apr 13, 2005, at 3:19 PM, Tim Rowledge wrote:

What do we do about making decently pickled platform trees for each release? I won't even pretend to have had time to understand any details of svn branches and so on.

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

This is probably a good time to ask if we are committing to make the 3.8 VM stuff be the first 64bit safe release? It seems like a reasonable idea to me but everyone has some work to do to make it happen properly.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Computer and car salesmen differ in that the latter know when they are lying.

Never mind must read vmdev messages a bit closer. On Apr 13, 2005, at 7:01 PM, John M McIntosh wrote:

Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/ sqMemoryAccess.h:19:20: config.h: No such file or directory

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

On Apr 13, 2005, at 15:01, Tim Rowledge wrote:

So let's just drop the no longer needed macro.

Sorry -- my confusion. The macro is still in there. (To support non-inlined compilation I undef it in my sqPlatformSpecific.h. A more compatible approach would be to test for SQ_VI_BYTES_PER_WORD defined and undef the macro conditionally. I took it out initially, then put it back with the sqPlatSpec undef before comitting.) The only issue remaining is the extra field in keyboard events to send a 32-bit wide char value.

The remaining confusion (and roll-back to 32-bit-only code) seems to have come from John's implementation of SVN which happily committed a stale sq.h against a newer version in the repository. John fixed this and I'm about to commit the 1-liner for keyboard events and then we should be up to date again and compiling cleanly in 64-bit mode.

I guess the lesson here is: please (please [please]), before committing anything to the trunk, make sure you are not committing a modified stale source file against a newer version in the repository. FWIW (this won't fix procedural problems with GUI-based interfaces ;-) here's what I do before committing anything (to any repo, anywhere, for any project):

- run 'svn st -u' in the dir I'm committing - if any files have '*' before them, they've changed in the repo since I last updated + move the local version aside (deleting the original name) + update just the conflicting file with 'svn update originalName.whatever', to get a fresh copy from the repo + diff the updated original version against my modified copy + copy (or propagated changes from) the new version back into the original version - svn commit -m 'hopefully without inadvertent roll-back'

If a GUI-based SVN cannot support this kind of caution by immitating the 'svn st -u' step then please be extra careful before committing (or just open a terminal window and run the status check manually ;-).

Thanks! Ian

Well the svnX tool does tell you you have a merge pending, and it does allow you to do fileMerge or diff. If one chooses not to it still doesn't prevent one from finding a bug that commits your stale version without asking. The only thing this would gain is on a commit you wouldn't have your stale version go up by accident since you would need to do an add first. Still I'll consider it until I decide if the tool is trustworthy enough.

On Apr 13, 2005, at 6:13 PM, Tim Rowledge wrote:

In message fe54c2bf414cbde186985bcdbfe31e4e@inria.fr Ian Piumarta ian.piumarta@inria.fr wrote:

...

 + move the local version aside (deleting the original name)
 + update just the conflicting file with 'svn update

originalName.whatever', to get a fresh copy from the repo + diff the updated original version against my modified copy + copy (or propagated changes from) the new version back into the original version

Why do you do this bit? Is it a lack of trust in the auto-merging hoo-hah stuff? I must admit I'm bit sniffy about the idea of anything automatically claiming to be able to tell me that "you changed some stuff and mickey changed some stuff but they didn't clash".

tim

Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: RC: Rewind Core

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

On Apr 13, 2005, at 15:16, Bert Freudenberg wrote:

What would be the One True Way of handling #flag:?

Having the CCodeGenerator remove it entirely (with a warning)?

Ian