I tried to build via "build.win32x86/squeak.cog.spur/mvm" but got an error with the resource file... ``` i686-w64-mingw32-windres \ --include-dir ../../platforms/win32/misc \ -D_WIN32 \ -DFILEVERSIONVALUES=,,, '-DFILEVERSIONSTRING="...\0"' \ -i Squeak.rc \ -o builddbg/vm/Squeak.res ==> i686-w64-mingw32-windres: Squeak.rc:7: syntax error make[1]: *** [../common/Makefile:296: Squeak.res] Error 1 ```
I see a reference at the top of [1] to this for Pharo but no direct resolution is mentioned. [1] http://forum.world.st/Compiling-the-windows-32-bits-vm-td5072691.html
[Squeak.rc:7]( https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/sq...) is... ``` FILEVERSION FILEVERSIONVALUES ``` and the value ",,," supplied for FILEVERSIONVALUES on the command line seems invalid.
I see Pharo has hardcoded the value... https://www.diffchecker.com/O36vXV5b https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/ph... ``` FILEVERSION 5,0,0,0 ```
and if I do the same in Squeak.rc the build completes. So should I submit a PR for that, or does anyone know how the command line "FILEVERSIONVALUES" is supposed to be supplied a proper value? Searching the repo doesn't give any hints... https://github.com/OpenSmalltalk/opensmalltalk-vm/search?q=FILEVERSIONVALUES
cheers -ben
Hi Ben,
I've never built squeak.cog.spur on windows (or any other platform :-)), but if you look at the appveyor log you can see that FILEVERSIONVALUES being defined:
https://ci.appveyor.com/project/OpenSmalltalk/vm/build/job/a6x5mg5uw7p8c882?...
hth, Alistair
On Wed, 19 Sep 2018 at 15:17, Ben Coman btc@openinworld.com wrote:
I tried to build via "build.win32x86/squeak.cog.spur/mvm" but got an error with the resource file...
i686-w64-mingw32-windres \ --include-dir ../../platforms/win32/misc \ -D_WIN32 \ -DFILEVERSIONVALUES=,,, '-DFILEVERSIONSTRING=\"...\\0\"' \ -i Squeak.rc \ -o builddbg/vm/Squeak.res ==> i686-w64-mingw32-windres: Squeak.rc:7: syntax error make[1]: *** [../common/Makefile:296: Squeak.res] Error 1
I see a reference at the top of [1] to this for Pharo but no direct resolution is mentioned. [1] http://forum.world.st/Compiling-the-windows-32-bits-vm-td5072691.html
[Squeak.rc:7](https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/sq...) is...
FILEVERSION FILEVERSIONVALUES
and the value ",,," supplied for FILEVERSIONVALUES on the command line seems invalid.
I see Pharo has hardcoded the value... https://www.diffchecker.com/O36vXV5b https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/ph...
FILEVERSION 5,0,0,0
and if I do the same in Squeak.rc the build completes. So should I submit a PR for that, or does anyone know how the command line "FILEVERSIONVALUES" is supposed to be supplied a proper value? Searching the repo doesn't give any hints... https://github.com/OpenSmalltalk/opensmalltalk-vm/search?q=FILEVERSIONVALUES
cheers -ben
Well spotted. But next puzzle... Where do "those" numbers come from? i.e... Appveyor defines... -DFILEVERSIONVALUES=2018,8,29,1622 My build defines... -DFILEVERSIONVALUES=,,,
Ahh, found it... common/Makefile.tools:RCFLAGS:= --include-dir $(PLATDIR)/win32/misc -D_WIN32 -DFILEVERSIONVALUES=$(SVNMAJOR),$(SVNMINOR),$(SVNREV),$(SVNBUILD) '-DFILEVERSIONSTRING="$(SVNMAJOR).$(SVNMINOR).$(SVNREV).$(SVNBUILD)\0"'
Damn! Forgetting to run ```updateSCCSversions``` on a fresh clone bites me again! :( :(
Better now, thx Alistair. cheers -ben
On Wed, 19 Sep 2018 at 21:25, Alistair Grant akgrant0710@gmail.com wrote:
Hi Ben,
I've never built squeak.cog.spur on windows (or any other platform :-)), but if you look at the appveyor log you can see that FILEVERSIONVALUES being defined:
https://ci.appveyor.com/project/OpenSmalltalk/vm/build/job/a6x5mg5uw7p8c882?...
hth, Alistair
On Wed, 19 Sep 2018 at 15:17, Ben Coman btc@openinworld.com wrote:
I tried to build via "build.win32x86/squeak.cog.spur/mvm" but got an
error with the resource file...
i686-w64-mingw32-windres \ --include-dir ../../platforms/win32/misc \ -D_WIN32 \ -DFILEVERSIONVALUES=,,, '-DFILEVERSIONSTRING=\"...\\0\"' \ -i Squeak.rc \ -o builddbg/vm/Squeak.res ==> i686-w64-mingw32-windres: Squeak.rc:7: syntax error make[1]: *** [../common/Makefile:296: Squeak.res] Error 1
I see a reference at the top of [1] to this for Pharo but no direct
resolution is mentioned.
[1]
http://forum.world.st/Compiling-the-windows-32-bits-vm-td5072691.html
[Squeak.rc:7](
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/sq...) is...
FILEVERSION FILEVERSIONVALUES
and the value ",,," supplied for FILEVERSIONVALUES on the command line
seems invalid.
I see Pharo has hardcoded the value... https://www.diffchecker.com/O36vXV5b
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/ph...
FILEVERSION 5,0,0,0
and if I do the same in Squeak.rc the build completes. So should I submit a PR for that, or does anyone know how the command
line "FILEVERSIONVALUES"
is supposed to be supplied a proper value? Searching the repo doesn't
give any hints...
https://github.com/OpenSmalltalk/opensmalltalk-vm/search?q=FILEVERSIONVALUES
cheers -ben
Hi Ben,
On Wed., 19 Sep. 2018, 16:50 Ben Coman, btc@openinworld.com wrote:
Well spotted. But next puzzle... Where do "those" numbers come from? i.e... Appveyor defines... -DFILEVERSIONVALUES=2018,8,29,1622 My build defines... -DFILEVERSIONVALUES=,,,
Yeah, sorry, I had to run for other things, but hoped it would provide enough of a clue.
Ahh, found it... common/Makefile.tools:RCFLAGS:= --include-dir $(PLATDIR)/win32/misc -D_WIN32 -DFILEVERSIONVALUES=$(SVNMAJOR),$(SVNMINOR),$(SVNREV),$(SVNBUILD) '-DFILEVERSIONSTRING="$(SVNMAJOR).$(SVNMINOR).$(SVNREV).$(SVNBUILD)\0"'
Damn! Forgetting to run ```updateSCCSversions``` on a fresh clone bites me again! :( :(
I have a script that I always use to run the compilation. :-) (I don't care about the overhead of repeatedly executing ```updateSCCSversions``)
Cheers, Alistair
Better now, thx Alistair.
cheers -ben
On Wed, 19 Sep 2018 at 21:25, Alistair Grant akgrant0710@gmail.com wrote:
Hi Ben,
I've never built squeak.cog.spur on windows (or any other platform :-)), but if you look at the appveyor log you can see that FILEVERSIONVALUES being defined:
https://ci.appveyor.com/project/OpenSmalltalk/vm/build/job/a6x5mg5uw7p8c882?...
hth, Alistair
On Wed, 19 Sep 2018 at 15:17, Ben Coman btc@openinworld.com wrote:
I tried to build via "build.win32x86/squeak.cog.spur/mvm" but got an
error with the resource file...
i686-w64-mingw32-windres \ --include-dir ../../platforms/win32/misc \ -D_WIN32 \ -DFILEVERSIONVALUES=,,, '-DFILEVERSIONSTRING=\"...\\0\"' \ -i Squeak.rc \ -o builddbg/vm/Squeak.res ==> i686-w64-mingw32-windres: Squeak.rc:7: syntax error make[1]: *** [../common/Makefile:296: Squeak.res] Error 1
I see a reference at the top of [1] to this for Pharo but no direct
resolution is mentioned.
[1]
http://forum.world.st/Compiling-the-windows-32-bits-vm-td5072691.html
[Squeak.rc:7](
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/sq...) is...
FILEVERSION FILEVERSIONVALUES
and the value ",,," supplied for FILEVERSIONVALUES on the command line
seems invalid.
I see Pharo has hardcoded the value... https://www.diffchecker.com/O36vXV5b
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/ph...
FILEVERSION 5,0,0,0
and if I do the same in Squeak.rc the build completes. So should I submit a PR for that, or does anyone know how the command
line "FILEVERSIONVALUES"
is supposed to be supplied a proper value? Searching the repo doesn't
give any hints...
https://github.com/OpenSmalltalk/opensmalltalk-vm/search?q=FILEVERSIONVALUES
cheers -ben
Hi Ben, On Wed, Sep 19, 2018 at 6:17 AM Ben Coman btc@openinworld.com wrote:
I tried to build via "build.win32x86/squeak.cog.spur/mvm" but got an error with the resource file...
i686-w64-mingw32-windres \ --include-dir ../../platforms/win32/misc \ -D_WIN32 \ -DFILEVERSIONVALUES=,,, '-DFILEVERSIONSTRING=\"...\\0\"' \ -i Squeak.rc \ -o builddbg/vm/Squeak.res ==> i686-w64-mingw32-windres: Squeak.rc:7: syntax error make[1]: *** [../common/Makefile:296: Squeak.res] Error 1
It should look something like this:
Aeolus.oscogvm$ grep FILEVERSIONVALUES build.win32x86/squeak.cog.spur/LOGF i686-w64-mingw32-windres --include-dir ../../platforms/win32/misc -D_WIN32 -DFILEVERSIONVALUES=2018,8,25,1913 '-DFILEVERSIONSTRING="2018.8.25.1913\0"' -i Squeak.rc -o build/vm/Squeak.res i686-w64-mingw32-windres --include-dir ../../platforms/win32/misc -D_WIN32 -DFILEVERSIONVALUES=2018,8,25,1913 '-DFILEVERSIONSTRING="2018.8.25.1913\0"' -i build/vm/Squeak.res -o build/vm/resource.o
where the values are the checkin date of the VM sources as produced by a compiled program. Here's the rule in common/Makefile.tools:
RCFLAGS:= --include-dir $(PLATDIR)/win32/misc -D_WIN32 -DFILEVERSIONVALUES=$(SVNMAJOR),$(SVNMINOR),$(SVNREV),$(SVNBUILD) '-DFILEVERSIONSTRING="$(SVNMAJOR).$(SVNMINOR).$(SVNREV).$(SVNBUILD)\0"'
And here's the rules for them:
SVNMAJOR := $(shell sed -e "s/^static.*GitRawRevisionString.*Rev: ([0-9][0-9][0-9][0-9]).*/\1/p" -e d $(PLATDIR)/Cross/vm/sqSCCSVersion.h | sed -e 's/^0*//') SVNMINOR := $(shell sed -e "s/^static.*GitRawRevisionString.*Rev: [0-9][0-9][0-9][0-9]([0-9][0-9]).*/\1/p" -e "s/^0*//" -e d $(PLATDIR)/Cross/vm/sqSCCSVersion.h | sed -e 's/^0*//')
So what I suspect has happened is that you've checked out the sources but not yet run scripts/updateSCCSVersions which has to be run before compiling for the first time. [This is IMO a bug with git, which will not embed any version control info in files on checkin or checkout; one has to use triggers, which means no info on the first checkout :-( ).
If you /can/ instead of just running scripts/updateSCCSVersions you might add a rule that will run scripts/updateSCCSVersions if SVNMAJOR ends up being empty. I'll then adapt that on the Mac builds.
Apologies. This is covered in README.md, but that's hardly a satisfactory answer.
```
I see a reference at the top of [1] to this for Pharo but no direct resolution is mentioned. [1] http://forum.world.st/Compiling-the-windows-32-bits-vm-td5072691.html
[Squeak.rc:7]( https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/sq...) is...
FILEVERSION FILEVERSIONVALUES
and the value ",,," supplied for FILEVERSIONVALUES on the command line seems invalid.
I see Pharo has hardcoded the value... https://www.diffchecker.com/O36vXV5b
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/ph...
FILEVERSION 5,0,0,0
and if I do the same in Squeak.rc the build completes. So should I submit a PR for that, or does anyone know how the command line "FILEVERSIONVALUES" is supposed to be supplied a proper value? Searching the repo doesn't give any hints...
https://github.com/OpenSmalltalk/opensmalltalk-vm/search?q=FILEVERSIONVALUES
cheers -ben
I'm curious if anyone has seen this writeup on VM performance
https://tratt.net/laurie/blog/entries/why_arent_more_users_more_happy_with_o...
I found the article very insightful and was curious how we stacked up.
Have written the author to ask about including us in future research.
Cheers. -Todd Blanchard
Hi Todd,
On 20.09.2018, at 10:28, Todd Blanchard tblanchard@mac.com wrote:
I'm curious if anyone has seen this writeup on VM performance
https://tratt.net/laurie/blog/entries/why_arent_more_users_more_happy_with_o...
I found the article very insightful and was curious how we stacked up.
Have written the author to ask about including us in future research.
Cheers. -Todd Blanchard
I know the author and share similar concerns. In fact, for stuff we do here with RSqueak/VM and GraalSqueak, we pay attention to at least some of the concerns Laurie mentions.
Have a look at SMark, which tries to give a reasonable benchmark set set.
http://smalltalkhub.com/#!/~StefanMarr/SMark
also, there's our benchmark runner that builds on SMark
http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/BenchmarkRunner.html
We also have a codespeed up here: http://speed.squeak.org/
Yea that does not all address the authors issues, but we try :D
Best regards -Tobias
Tobias,
That's excellent to know... I wasn't aware that this was being looked at. Something that's been in the back of my mind for a while is trying to measure JIT performance vs. JIT code cache size, architecture being run on, and workload. As I understand it, the JIT code cache is a fixed size (~1meg iirc) which doesn't make a lot of sense to me given the variance in CPU cache size (generally in the range of 512k-4m depending on whether you're running on Intel/AMD/ARM, desktop/server, low/high end, HT enabled/disabled, and oddball/extreme CPU configurations like the Intel 5775C with it's 128meg LLC) and then there's the cost of potentially thrashing the JIT cache vs maintaining a larger cache despite the fact that it might exceed the capacity of the CPU cache. (However to measure this I think a few new VM params would be needed: a r/w JIT cache size, JIT cache code evictions (since last full gc?), JIT cache code additions (since last full gc?), Avg cache code size... the current machine code method/compaction counts are a good start but a bit coarse). Just thought I'd throw this out there since it seemed apropos...
Thanks, Phil
On Thu, Sep 20, 2018, 5:02 AM Tobias Pape Das.Linux@gmx.de wrote:
Hi Todd,
On 20.09.2018, at 10:28, Todd Blanchard tblanchard@mac.com wrote:
I'm curious if anyone has seen this writeup on VM performance
https://tratt.net/laurie/blog/entries/why_arent_more_users_more_happy_with_o...
I found the article very insightful and was curious how we stacked up.
Have written the author to ask about including us in future research.
Cheers. -Todd Blanchard
I know the author and share similar concerns. In fact, for stuff we do here with RSqueak/VM and GraalSqueak, we pay attention to at least some of the concerns Laurie mentions.
Have a look at SMark, which tries to give a reasonable benchmark set set.
http://smalltalkhub.com/#!/~StefanMarr/SMark
also, there's our benchmark runner that builds on SMark
http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/BenchmarkRunner.html
We also have a codespeed up here: http://speed.squeak.org/
Yea that does not all address the authors issues, but we try :D
Best regards -Tobias
Hi:
On 20 Sep 2018, at 10:02, Tobias Pape Das.Linux@gmx.de wrote:
Have a look at SMark, which tries to give a reasonable benchmark set set.
As the author of SMark, I cannot recommend to still use it.
Instead, I’d highly recommend https://github.com/smarr/are-we-fast-yet/tree/master/benchmarks/Smalltalk While it uses file syntax for the benchmarks, there is support for Squeak/Pharo, too.
SMark should be avoided because its methodology is flawed (especially considering the context of the blog post). The benchmarks in the Are We Fast Yet project are also larger and thus a little more representative.
Best regards Stefan
vm-dev@lists.squeakfoundation.org