bug in svnx and rollback of /trunk/platforms/Cross/vm/sq.h needed (1172)

Found a neat bug in the mac version of svnX 0.8.
If you select one item in your list to commit, hit the commit button.  
Then say accidently hit the
flat mode/smart mode check box, why then it cheerfully re-select *all*  
files that are pending, which then is processed by
the pending/in progress commit, thus you commit a bogus version of  
trunk/platforms/Cross/vm/sq.h

I'll note that the version of sq.h Ian posted in 1150 was missing some  
changes from last year.
Now someone will need to repost the version from 1150 or rollback/copy?  
I'm not quite sure how
to do this. I had sent a note earlier to Ian (10 minutes ago) asking  
him to check my copy of sq.h with
his 64bit version.

--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

On Apr 13, 2005, at 14:01, John M McIntosh wrote:

> I'll note that the version of sq.h Ian posted in 1150 was missing some
> changes from last year.
> Now someone will need to repost the version from 1150 or
> rollback/copy? I'm not quite sure how
> to do this. I had sent a note earlier to Ian (10 minutes ago) asking
> him to check my copy of sq.h with
> his 64bit version.

And he replied, 10 minutes ago.  Of the three issues: one wasn't, one
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).

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.

Ian

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 <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

In message <[hidden email]>
          Ian Piumarta <[hidden email]> 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, [hidden email], http://sumeru.stanford.edu/tim
Oxymorons: Terribly pleased

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

Agreed.

Cheers,
   - Andreas

Tim Rowledge wrote:

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

Am 14.04.2005 um 00:01 schrieb Tim Rowledge:

While we're at it ... there seems to be a new sport inventing ways of
making "self flag: #bla" compile. LargeIntegersPlugin implements #flag:
as empty slang method. One of Ian's headers makes flag() an empty
inlined C function. Ned's CairoPlugin header has a preprocessor macro
to #define flag(). We ourselves made the C translator generate a
comment instead for #flag:.

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

- Bert -

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

In message <[hidden email]>
          Andreas Raab <[hidden email]> wrote:

>  > So let's just drop the no longer needed macro.
>
> Agreed.
Good. That was nice and simple - makes a nice change this week.

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. What I _do_ have is a pickled platform tree for 3.6g2, 3.7a1&2, 3.
7b1-6 and 3.8b1-3. They are of course in RISC OS format which makes them a tad
less useful to anyone else without some CR/LF & name processing fiddles.

tim
--
Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim
Useful random insult:- His future is behind schedule.  -- Bob Thaves

In message <[hidden email]>
          Bert Freudenberg <[hidden email]> wrote:


> What would be the One True Way of handling #flag:?
Hmm, we should probably flag it.

Best option is to fix the code so no #flags are needed. Making CCG null it is probaly the most efficient alternative.

tim
--
Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim
Strange OpCodes: CBA: Compare if Biorhythms Amenable

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 <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

In message <[hidden email]>
          Tim Rowledge <[hidden email]> wrote:

> and so on. What I _do_ have is a pickled platform tree for 3.6g2, 3.7a1&2, 3.
> 7b1-6 and 3.8b1-3.
Hmm, I take some of that back. Nothing for 3.7a1&2, 3.8b1&2 for some reason probably connected to incompetence.

tim
--
Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim
Strange OpCodes: SDLI: Shift Disk Left Immedite

On Apr 13, 2005, at 3:41 PM, John M McIntosh wrote:

> 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.

You probably meant 'tag' rather than 'branch' and 'tags folder' rather
than 'branch folder'.

> Can't say I know what the proper svn cmd would be tho.

Just copy the trunk (at the revision you'd like to immortalise) into a
fresh tag folder (equivalent to 'tagging' a particular revision in CVS)
within the repo itself:

prompt$ svn cp -r <revision-to-immortalise>
http://squeak.hpl.hp.com/svn/squeak/trunk 
http://squeak.hpl.hp.com/svn/squeak/tags/platform-major.minor-update

Cheers,
Ian

In message <[hidden email]>
          Ian Piumarta <[hidden email]> 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, [hidden email], http://sumeru.stanford.edu/tim
Strange OpCodes: RC: Rewind Core

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, [hidden email], http://sumeru.stanford.edu/tim
Computer and car salesmen differ in that the latter know when they are lying.

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:
--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

Well if I could compile it.  I get this below.
Is config.h a file that comes out of some magical unix command  
invocation? Or is it a result of VMMaker?

/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:19:20: config.h: No such file or directory
/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:25:3: warning: #warning
/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:26:3: warning: #warning  
***************************************************
/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:27:3: warning: #warning *
/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:28:3: warning: #warning * interp.h not found --  
defaulting to a 32-bit VM
/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:29:3: warning: #warning *
/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:30:3: warning: #warning * update your image-side VM  
sources to the latest
/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:31:3: warning: #warning * version to avoid this  
message
/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:32:3: warning: #warning *
/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:33:3: warning: #warning  
***************************************************
/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:34:3: warning: #warning
/Users/johnmci/Documents/Squeak3.8.0/platforms/Cross/vm/
sqMemoryAccess.h:48:3: #error host is neither 32- nor 64-bit?



On Apr 13, 2005, at 6:18 PM, Tim Rowledge wrote:
--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

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 <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===