Squeak.rc FILEVERSIONVALUES
Locked
 
|
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. [Squeak.rc:7](https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/squeak.cog.spur/Squeak.rc#L7) is... ``` FILEVERSION FILEVERSIONVALUES ``` and the value ",,," supplied for FILEVERSIONVALUES on the command line seems invalid. I see Pharo has hardcoded the value... ``` 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... cheers -ben |
Re: Squeak.rc FILEVERSIONVALUES
|
|
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?fullLog=true hth, Alistair On Wed, 19 Sep 2018 at 15:17, Ben Coman <[hidden email]> 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/squeak.cog.spur/Squeak.rc#L7) 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/pharo.cog.spur/Pharo.rc#L7 > ``` > 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 <[hidden email]> wrote:
|
Re: Squeak.rc FILEVERSIONVALUES
|
|
Hi Ben, On Wed., 19 Sep. 2018, 16:50 Ben Coman, <[hidden email]> wrote:
Yeah, sorry, I had to run for other things, but hoped it would provide enough of a clue.
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
|
Re: Squeak.rc FILEVERSIONVALUES
|
|
In reply to this post by Ben Coman
Hi Ben, On Wed, Sep 19, 2018 at 6:17 AM Ben Coman <[hidden email]> wrote:
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.
_,,,^..^,,,_ best, Eliot |
Why Aren’t More Users More Happy With Our VMs?
|
|
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_our_vms_part_2.html 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 |
Re: Why Aren’t More Users More Happy With Our VMs?
|
|
Hi Todd, > On 20.09.2018, at 10:28, Todd Blanchard <[hidden email]> 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_our_vms_part_2.html > > 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 <[hidden email]> wrote:
|
Re: Why Aren’t More Users More Happy With Our VMs?
|
|
In reply to this post by Tobias Pape
Hi: > On 20 Sep 2018, at 10:02, Tobias Pape <[hidden email]> wrote: > > Have a look at SMark, which tries to give a reasonable benchmark set set. > > http://smalltalkhub.com/#!/~StefanMarr/SMark 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 -- Stefan Marr School of Computing, University of Kent http://stefan-marr.de/research/ |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |