Spur corrupts large images when saving
Locked
123
123
Re: Ian's cmake design (was: svn git bridge?)
 
|
David, > On Apr 23, 2016, at 3:13 PM, David T. Lewis <[hidden email]> wrote: > > >> On Sat, Apr 23, 2016 at 10:44:02AM -0700, Eliot Miranda wrote: >> >>> On Apr 23, 2016, at 10:30 AM, Tobias Pape <[hidden email]> wrote: >>> >>> PS: Personally (i.e. IMHO), I think that IF we go with cmake, we should follo Ians way with >>> probably some mix of the self vm stuff. It can really work. And it can also help us >>> getting things compiled on MS compilers, btw. >> >> What do you mean by "Ian's way" exactly? Please describe it. >> >> Things I know: >> - Ian's autoconf code (platforms/unix/conf, the various additional snippets that get included when one builds the autoconf support, rather than things that get computed at build time) is extremely difficult to work with >> - gmake files work with MS compilers too > > My experience is different. I find it a bit obscure in the sense that it > would benefit from some better documentation and comments in the cmake files. > > Aside from that, Ian got the design dead right. Cmake handles the overall > build. The VM build procedures are in a small number of files. Configurations > that are specific to some part of the build tree are located with the source, > and versioned with the source files to which they apply. And how is that significantly different from the gmake files? Gnu make ha goes the overall build, the VM build procedures are in a small number of files. Configurations that are specific to some part of the build tree are located with the source, and versioned with the source files to which they apply. None of this is specific to cmake. What is specific to both cmake and autoconf is their being Makefile compilers, with all the difficulties that implies (learning a specialized language, waiting for compiles, interpreting compile-time and run-time errors and mapping them back to the source. > Looking back at the last seven years or so, I would say: > > - The number of changes to the cmake procedures has been minimal. > - Building a VM with Ian's procedure is still remarkably easy. > - The total amount of code (cmake files) required to make this work is small. > - In the few cases where I needed to change something, I have been able to > figure out what to do. > - Despite years of upgrades (sic) to my operating systems and compilers, > it still works. Looking back at the past 9 years I would say that Andreas' gnu makefiles for Windows never stopped working, were much easier to extend to Cog and Newspeak and the building of platform-specific Newspeak installers was straight-forward. > > I have very little patience for fiddling around with build systems, and > no patience whatsoever for autotools. But I have had no trouble using > and occasionally modifying Ian's cmake build procedures. Have you used the gnu makefiles? Have you extended them? > > Dave > |
Re: Ian's cmake design (was: svn git bridge?)
|
|
On Sat, Apr 23, 2016 at 05:10:37PM -0700, Eliot Miranda wrote: > > David, > > > On Apr 23, 2016, at 3:13 PM, David T. Lewis <[hidden email]> wrote: > > > > > >> On Sat, Apr 23, 2016 at 10:44:02AM -0700, Eliot Miranda wrote: > >> > >>> On Apr 23, 2016, at 10:30 AM, Tobias Pape <[hidden email]> wrote: > >>> > >>> PS: Personally (i.e. IMHO), I think that IF we go with cmake, we should follo Ians way with > >>> probably some mix of the self vm stuff. It can really work. And it can also help us > >>> getting things compiled on MS compilers, btw. > >> > >> What do you mean by "Ian's way" exactly? Please describe it. > >> > >> Things I know: > >> - Ian's autoconf code (platforms/unix/conf, the various additional snippets that get included when one builds the autoconf support, rather than things that get computed at build time) is extremely difficult to work with > >> - gmake files work with MS compilers too > > > > My experience is different. I find it a bit obscure in the sense that it > > would benefit from some better documentation and comments in the cmake files. > > > > Aside from that, Ian got the design dead right. Cmake handles the overall > > build. The VM build procedures are in a small number of files. Configurations > > that are specific to some part of the build tree are located with the source, > > and versioned with the source files to which they apply. > > And how is that significantly different from the gmake files? Gnu make ha goes the overall build, the VM build procedures are in a small number of files. Configurations that are specific to some part of the build tree are located with the source, and versioned with the source files to which they apply. None of this is specific to cmake. > > What is specific to both cmake and autoconf is their being Makefile compilers, with all the difficulties that implies (learning a specialized language, waiting for compiles, interpreting compile-time and run-time errors and mapping them back to the source. > I don't know. My point is that Ian's design is well considered, and works very well in my experience. > > Looking back at the last seven years or so, I would say: > > > > - The number of changes to the cmake procedures has been minimal. > > - Building a VM with Ian's procedure is still remarkably easy. > > - The total amount of code (cmake files) required to make this work is small. > > - In the few cases where I needed to change something, I have been able to > > figure out what to do. > > - Despite years of upgrades (sic) to my operating systems and compilers, > > it still works. > > Looking back at the past 9 years I would say that Andreas' gnu makefiles for Windows never stopped working, were much easier to extend to Cog and Newspeak and the building of platform-specific Newspeak installers was straight-forward. > I have no problem believing that :-) > > > > I have very little patience for fiddling around with build systems, and > > no patience whatsoever for autotools. But I have had no trouble using > > and occasionally modifying Ian's cmake build procedures. > > Have you used the gnu makefiles? Have you extended them? > If you are referring to e.g. the acinclude.m4 and Makefile.inc files, then yes I have used and extended them. Dave |
Re: Ian's cmake design (was: svn git bridge?)
|
|
Dave, > On Apr 23, 2016, at 7:56 PM, David T. Lewis <[hidden email]> wrote: > > >> On Sat, Apr 23, 2016 at 05:10:37PM -0700, Eliot Miranda wrote: >> >> David, >> >>> On Apr 23, 2016, at 3:13 PM, David T. Lewis <[hidden email]> wrote: >>> >>> >>>>> On Sat, Apr 23, 2016 at 10:44:02AM -0700, Eliot Miranda wrote: >>>>> >>>>> On Apr 23, 2016, at 10:30 AM, Tobias Pape <[hidden email]> wrote: >>>>> >>>>> PS: Personally (i.e. IMHO), I think that IF we go with cmake, we should follo Ians way with >>>>> probably some mix of the self vm stuff. It can really work. And it can also help us >>>>> getting things compiled on MS compilers, btw. >>>> >>>> What do you mean by "Ian's way" exactly? Please describe it. >>>> >>>> Things I know: >>>> - Ian's autoconf code (platforms/unix/conf, the various additional snippets that get included when one builds the autoconf support, rather than things that get computed at build time) is extremely difficult to work with >>>> - gmake files work with MS compilers too >>> >>> My experience is different. I find it a bit obscure in the sense that it >>> would benefit from some better documentation and comments in the cmake files. >>> >>> Aside from that, Ian got the design dead right. Cmake handles the overall >>> build. The VM build procedures are in a small number of files. Configurations >>> that are specific to some part of the build tree are located with the source, >>> and versioned with the source files to which they apply. >> >> And how is that significantly different from the gmake files? Gnu make ha goes the overall build, the VM build procedures are in a small number of files. Configurations that are specific to some part of the build tree are located with the source, and versioned with the source files to which they apply. None of this is specific to cmake. >> >> What is specific to both cmake and autoconf is their being Makefile compilers, with all the difficulties that implies (learning a specialized language, waiting for compiles, interpreting compile-time and run-time errors and mapping them back to the source. > > I don't know. > > My point is that Ian's design is well considered, and works very well in my experience. > > >>> Looking back at the last seven years or so, I would say: >>> >>> - The number of changes to the cmake procedures has been minimal. >>> - Building a VM with Ian's procedure is still remarkably easy. >>> - The total amount of code (cmake files) required to make this work is small. >>> - In the few cases where I needed to change something, I have been able to >>> figure out what to do. >>> - Despite years of upgrades (sic) to my operating systems and compilers, >>> it still works. >> >> Looking back at the past 9 years I would say that Andreas' gnu makefiles for Windows never stopped working, were much easier to extend to Cog and Newspeak and the building of platform-specific Newspeak installers was straight-forward. > > I have no problem believing that :-) > >>> >>> I have very little patience for fiddling around with build systems, and >>> no patience whatsoever for autotools. But I have had no trouble using >>> and occasionally modifying Ian's cmake build procedures. >> >> Have you used the gnu makefiles? Have you extended them? > > If you are referring to e.g. the acinclude.m4 and Makefile.inc files, then > yes I have used and extended them. No, I'm referring to the gnu makefiles used to build win32 and Mac OS X cog. I posted their svn urls in my point by point comparison of them with cmake. > Dave |
Re: Ian's cmake design (was: svn git bridge?)
|
|
On Sat, Apr 23, 2016 at 08:08:04PM -0700, Eliot Miranda wrote: > > Dave, > > > On Apr 23, 2016, at 7:56 PM, David T. Lewis <[hidden email]> wrote: > > > > > >> On Sat, Apr 23, 2016 at 05:10:37PM -0700, Eliot Miranda wrote: > >> > >> David, > >> > >>> On Apr 23, 2016, at 3:13 PM, David T. Lewis <[hidden email]> wrote: > >>> > >>> > >>>>> On Sat, Apr 23, 2016 at 10:44:02AM -0700, Eliot Miranda wrote: > >>>>> > >>>>> On Apr 23, 2016, at 10:30 AM, Tobias Pape <[hidden email]> wrote: > >>>>> > >>>>> PS: Personally (i.e. IMHO), I think that IF we go with cmake, we should follo Ians way with > >>>>> probably some mix of the self vm stuff. It can really work. And it can also help us > >>>>> getting things compiled on MS compilers, btw. > >>>> > >>>> What do you mean by "Ian's way" exactly? Please describe it. > >>>> > >>>> Things I know: > >>>> - Ian's autoconf code (platforms/unix/conf, the various additional snippets that get included when one builds the autoconf support, rather than things that get computed at build time) is extremely difficult to work with > >>>> - gmake files work with MS compilers too > >>> > >>> My experience is different. I find it a bit obscure in the sense that it > >>> would benefit from some better documentation and comments in the cmake files. > >>> > >>> Aside from that, Ian got the design dead right. Cmake handles the overall > >>> build. The VM build procedures are in a small number of files. Configurations > >>> that are specific to some part of the build tree are located with the source, > >>> and versioned with the source files to which they apply. > >> > >> And how is that significantly different from the gmake files? Gnu make ha goes the overall build, the VM build procedures are in a small number of files. Configurations that are specific to some part of the build tree are located with the source, and versioned with the source files to which they apply. None of this is specific to cmake. > >> > >> What is specific to both cmake and autoconf is their being Makefile compilers, with all the difficulties that implies (learning a specialized language, waiting for compiles, interpreting compile-time and run-time errors and mapping them back to the source. > > > > I don't know. > > > > My point is that Ian's design is well considered, and works very well in my experience. > > > > > >>> Looking back at the last seven years or so, I would say: > >>> > >>> - The number of changes to the cmake procedures has been minimal. > >>> - Building a VM with Ian's procedure is still remarkably easy. > >>> - The total amount of code (cmake files) required to make this work is small. > >>> - In the few cases where I needed to change something, I have been able to > >>> figure out what to do. > >>> - Despite years of upgrades (sic) to my operating systems and compilers, > >>> it still works. > >> > >> Looking back at the past 9 years I would say that Andreas' gnu makefiles for Windows never stopped working, were much easier to extend to Cog and Newspeak and the building of platform-specific Newspeak installers was straight-forward. > > > > I have no problem believing that :-) > > > >>> > >>> I have very little patience for fiddling around with build systems, and > >>> no patience whatsoever for autotools. But I have had no trouble using > >>> and occasionally modifying Ian's cmake build procedures. > >> > >> Have you used the gnu makefiles? Have you extended them? > > > > If you are referring to e.g. the acinclude.m4 and Makefile.inc files, then > > yes I have used and extended them. > > No, I'm referring to the gnu makefiles used to build win32 and Mac OS X cog. I posted their svn urls in my point by point comparison of them with cmake. > No, I have not used these, and I cannot comment one way or another. Certainly an approach that works all platforms is a good thing, regardless of the build tools. Dave |
|
|
In reply to this post by Eliot Miranda-2
On Sun, Apr 24, 2016 at 3:33 AM, Eliot Miranda <[hidden email]> wrote: > > Hi Tobias, > > On Sat, Apr 23, 2016 at 10:55 AM, Tobias Pape <[hidden email]> wrote: >> >> >> >> On 23.04.2016, at 19:44, Eliot Miranda <[hidden email]> wrote: >> >> > >> > Hi Tobias, >> > >> >> On Apr 23, 2016, at 10:30 AM, Tobias Pape <[hidden email]> wrote: >> >> >> >> >> >> >> >>> On 23.04.2016, at 19:21, Eliot Miranda <[hidden email]> wrote: >> >>> >> >>> Hi Fabio, >> >>> >> >>> and the "if not, why not?" question is a request for information, not an expression of annoyance. Subversion tags update the source in checkin. I remember Igor saying that he couldn't find out how to make gig do the same with version numbers (forgive me if my recollection is incorrect). But if git doesn't support this then we need to invent some scheme that does work, for example doing two commits, one to generate a hash and another to commit a tag. But we need sensible increment isn't version numbers, not stupid hashes. It has to be a requirement that one can tell from the output of >> >>> myvm -version >> >>> yourvm -version >> >>> whether the VMs are built from the same or different versions of the source and which one is more up-to-date, and that this depends on version number, not irrelevancies such as build date. >> >> >> >> I did such stuff like 4 years ago for self (don't ask why) >> >> I changed their whole VM build process to CMake. >> >> >> >> Here's some parts that vaguely do what you want want: >> >> >> >> This uses "date" to generate a vm build date (lines 12 and following) >> >> and "git" to extract VCS infos (lines 39 and following) >> >> https://github.com/russellallen/self/blob/master/vm/cmake/configureVmDate.cmake.in >> >> (it is namend .in because it gets configured itself from elsewhere) >> >> >> >> It is clearly possible to switch all the stuff to git and cmake and I'd like to see that happen. >> >> I would love to have time for that (although it regularly makes me angry :D). >> >> >> >> Best regards >> >> -Tobias >> >> >> >> PS: Personally (i.e. IMHO), I think that IF we go with cmake, we should follo Ians way with >> >> probably some mix of the self vm stuff. It can really work. And it can also help us >> >> getting things compiled on MS compilers, btw. >> > >> > What do you mean by "Ian's way" exactly? Please describe it. >> > >> > Things I know: >> > - Ian's autoconf code (platforms/unix/conf, the various additional snippets that get included when one builds the autoconf support, rather than things that get computed at build time) is extremely difficult to work with >> >> Ian's unix conf uses CMake for a while now. >> There's no autoconf. >> Thers no platforms/unix/conf, neither in >> http://www.squeakvm.org/svn/squeak/trunk/platforms/unix/ >> nor in >> https://github.com/fniephaus/squeak/tree/master/platforms/unix > > > Yes, I know. I also know that, for example, http://www.squeakvm.org/svn/squeak/trunk/platforms/unix/cmake/Plugins.cmake is /not/ easy to work with. It is essentially impenetrable without significant thought. I will critique fully below. > >> >> So I'm a bit confused about what you refer to. >> >> > - gmake files work with MS compilers too >> > >> > I am strongly in favor of gmake files. It's /much/ easier to work with. >> >> Sorry, i beg to differ. >> >> > Please, please, please let's limit the use of cmake to generating a config file as I've already discussed. >> >> you mean gnu make? > > > Yes. And as examples I invite you to read, for example, > > http://www.squeakvm.org/svn/squeak/branches/Cog/ > build.macos64x64/common/Makefile.app > build.macos64x64/common/Makefile.app.newspeak > build.macos64x64/common/Makefile.app.squeak.cog > build.macos64x64/common/Makefile.flags > build.macos64x64/common/Makefile.plugin > build.macos64x64/common/Makefile.rules > build.macos64x64/common/Makefile.vm > > build.macos64x64/pharo.cog.spur/Makefile > build.macos64x64/squeak.cog.spur/Makefile > build.macos64x64/squeak.stack.spur/Makefile > > build.win32x86/common/Makefile > build.win32x86/common/Makefile.plugin > build.win32x86/common/Makefile.rules > > > So what are the trade offs? I'll mark cmake plusses with '+', gmake advantages over cmake '-'. > > + cmake and autoconf include systems for computing a platform-specific config.h file from aplatform-independent template that identifies a platform's basic facilities, word size, available APIs, etc. This is of value. I've described earlier in this thread how I want to use this, by generating a single copy of the platform-speciifc file per platform-specific build directory, where each build directory includes several distinct VMs (squeak vs pharo vs newspeak * context vs stack vs cog vs sista * v3 vs spur) and a single copy of support libraries such as Bochs, Cairo et al. Naive questions about using a one-time generated config.h... Is this enough to support cross-compilation with cmake itself? Where in the priorities is cross-compilation? Of minor concern (because I've no clue of the impact)... "Rumprun unikernels are always cross-compiled. In practical terms, that statement means that the compiler will never run on a Rumprun unikernel. Instead, the compiler always runs on a build host (e.g. a regular Linux/BSD system)." cheers -ben |
|
|
In reply to this post by Eliot Miranda-2
Hi all,
The CMakeVMakerSqueak is getting close enough that it is worth considering for going to Ian's design (its what I have in mind) My time is very limited so I cannot get this done ASAP. However, the design seems solid to me and there is no reason why the tool cannot be used to generate what Ian's approach.(Imho, it does this now) I am currently focusing (at most, one day a week) on writing Help documentation as I create a configuration. I am very willing to provide feedback via email (every day after my day job) for anybody who wants to get this done. Steps remaining (excluding refactoring) are: 1. Document workflows. 2. Complete all configurations to generate what Eliot currently supports. 3. Decouple from the pharo CMakeVMMaker 4. Automate the creation of CMake Templates/Components by parsing CMake help output and creating Squeak CMake objects (the idea is similar to Seaside Components for CMake) I think the design is loosely coupled and makes sense. I too think Ian's CMake work is awesome. I currently use his approach for generating CMakeLists.txt output for the plugins. The mantra for the project is "CMAKE drives the development decisions" . thank you for your time. tty
|
Re: svn git bridge? (was: Spur corrupts large images when saving)
|
|
In reply to this post by Ben Coman
On Sun, Apr 24, 2016 at 8:00 AM, Ben Coman <[hidden email]> wrote:
I don't know but I would have thought that's orthogonal to the issue/ Whatever cross compilation scheme is used one has to use the includes for the platform. So the config.h would be generated w.r.t. the target platform not the host. That's no different. Where in the priorities is cross-compilation? Well, I'd love to use more cross compilation; things would be much faster. But again it's additional work to get going. Anyone who gets cross compilation to any target running on Mac OS X please let me know; I'm interested. Of minor concern (because I've no clue of the impact)... "Rumprun _,,,^..^,,,_ best, Eliot |
Re: Repository name(s) [was Re: [Vm-dev] svn git bridge? ...]
|
|
In reply to this post by Eliot Miranda-2
On 23 April 2016 at 10:01, Eliot Miranda <[hidden email]> wrote:
FWIW I'd go with "cogvm". Short, sweet, to the point. frank |
|
Wouldn't it be good to have it under:
Why do you want to set up another GitHub organization for one or two repositories? I'd go with: and for the original Squeak VM: Best, Fabio -- On Mon, Apr 25, 2016 at 11:57 PM Frank Shearar <[hidden email]> wrote:
|
Re: Repository name(s) [was Re: [Vm-dev] svn git bridge? ...]
|
|
There is also already: https://github.com/squeakvm > On 26 Apr 2016, at 00:12, Fabio Niephaus <[hidden email]> wrote: > > Wouldn't it be good to have it under: > https://github.com/squeak-smalltalk/ ? > > Why do you want to set up another GitHub organization for one or two repositories? > > I'd go with: > https://github.com/squeak-smalltalk/cogvm > and for the original Squeak VM: > https://github.com/squeak-smalltalk/squeakvm > > Best, > Fabio > > -- > > On Mon, Apr 25, 2016 at 11:57 PM Frank Shearar <[hidden email]> wrote: > On 23 April 2016 at 10:01, Eliot Miranda <[hidden email]> wrote: > > Hi All, > > one very important question is what are the names of the top level git repository and sub modules? Before you suggest something please check that the name isn't already used on github. > > Here are some suggestions > > http://cogvm.github.io/.com > http://backtothefuture.github.io/.com > https://opensmalltalkvm.github.io/com > > > _,,,^..^,,,_ (phone) > > FWIW I'd go with "cogvm". Short, sweet, to the point. > > frank |
|
|
In reply to this post by Eliot Miranda-2
On Sun, Apr 24, 2016 at 1:03 AM, Eliot Miranda <[hidden email]> wrote: > >> On Apr 23, 2016, at 10:01 AM, Eliot Miranda <[hidden email]> wrote: >> >> Hi All, >> >> one very important question is what are the names of the top level git repository and sub modules? Before you suggest something please check that the name isn't already used on github. >> >> Here are some suggestions >> >> http://cogvm.github.io/.com >> http://backtothefuture.github.io/.com >> https://opensmalltalkvm.github.io/com > > Or github.com/ > cogvm > backtothefuture > opensmalltalkvm > of course Technically... Previous discussion on moving to git raised the concern about being tied too tightly to a particular third party infrastructure. To guard against this, in case moving on from github to another git service is required in the future, consider using a custom second-level domain per [1] rather than the default third-level one under github.io. So... cog.com|.net|.org|.io and cogvm.com|.net are all taken[2]. cogvm.org|.io are both available. "io" is where all the trendy kids hang out these days" However I believe its better to avoid competing against another holder of the primary .com. backtothefuture.com|.net|.org are all taken [2] backtothefuture.io is available. opensmalltalkvm.com|.net|.org|.io are all available. I believe its best to grab the lot, or at least .com redirected to the one you use, to avoid anyone swooping in later to repurpose the primary domain. Philosphically... IIUC the repository is more than just cog, containing also the classic interpeter. So cogvm seems a bit narrow in scope. backtothefuture initially struck me as too loaded with insider meaning, but its since grown on me as a sense of innovation plus history, and an invitation to the broader programming community perhaps dissatisfied with their status quo. However branding wise you it competes against the popular movie with backtothefuture having 541 Mgoogs**. So the project could end hidden in the noise. Maybe consider bttfvm(160 googs), btfvm(2000 googs). OpenSmalltalkVM reminds me of the tagline 'Eliot Miranda to deliver the keynote presentation "Cog - The Open Source Smalltalk VM" ' that caught my eye recently [3]. This resonated with me as being very inclusive and marketable in broadening Cog's user base to attract outside interest. > Wouldn't it be good to have it under: > https://github.com/squeak-smalltalk/ ? The VM today is used also by Newspeak and Pharo. We all do mostly our own thing at the Image level, but we share the VM. It would be nice to have a more generic project name to encompass this. Also Eliot and Clement are doing invovative VM design that could appeal to a broader community as mentioned by Chris[4]. A VM less tied to a specific program run on it might facilitate outsider participation (i.e. $$) directly in the VM rather than just taking the new ideas elsewhere. And completely wild speculation... imagine Dolphin went open source for lack of a 64 bit VM and it was easiest for them to move their Image over to adopt Cog as their VM. Picking up even one more user of the VM could be worth rebranding. Maybe this is not likely, but its less likely with the VM branded for particular Image not their own. cheers -ben ** goog - measure of world uniqueness per google search results. [1] https://help.github.com/articles/using-a-custom-domain-with-github-pages/ [2] https://www.namecheap.com/domains/whois.aspx [3] http://www.ooplu.com [4] http://forum.world.st/Simulator-tutorial-tp4888841p4888883.html |
|
|
In reply to this post by Frank Shearar-3
+1
|
|
|
In reply to this post by fniephaus
because the VM exceeds squeak? … and because then we can have more than one project, and keep them well organised. Esteban
|
Re: Repository name(s) [was Re: [Vm-dev] svn git bridge? ...]
|
|
In reply to this post by EstebanLM
On 26.04.2016, at 07:52, Esteban Lorenzano <[hidden email]> wrote: > >> On 25 Apr 2016, at 23:57, Frank Shearar <[hidden email]> wrote: >> >> On 23 April 2016 at 10:01, Eliot Miranda <[hidden email]> wrote: >> >> Hi All, >> >> one very important question is what are the names of the top level git repository and sub modules? Before you suggest something please check that the name isn't already used on github. >> >> Here are some suggestions >> >> http://cogvm.github.io/.com >> http://backtothefuture.github.io/.com >> https://opensmalltalkvm.github.io/com >> >> >> _,,,^..^,,,_ (phone) >> >> FWIW I'd go with "cogvm". Short, sweet, to the point. > > +1 That would imply to ditch the interpreter vm altogether. so -0 from me… Best -Tobias > >> >> frank |
Re: Repository name(s) [was Re: [Vm-dev] svn git bridge? ...]
|
|
Hi Tobias,
On Mon, May 2, 2016 at 7:10 AM, Tobias Pape <[hidden email]> wrote:
That's not the intention. What we need is some effort to integrate the ContextInterpreter back into VMMaker.oscog. David doesn't have the time. The Interpreter in VMMaker.oscog is both ahead and behind the VMMaker Interpreter. The VMMaker.oscog one has Andreas' profiler improvements, but it hasn't been refactored to not inherit from ObjectMemory and and fixes that have been applied to VMMaker's Interpreter could do with being integrated. But it's not a hinge join, just not one I or David have time for. Is there anyone out there with curiosity for the VM who does have some time? Tobias, any students you can point at the task? It's a refactoring job and I'll hand hold.
_,,,^..^,,,_ best, Eliot |
Re: Repository name(s) [was Re: [Vm-dev] svn git bridge? ...]
|
|
Hi Eliot, On 02.05.2016, at 20:54, Eliot Miranda <[hidden email]> wrote: > >> Hi Tobias, >> >> On Mon, May 2, 2016 at 7:10 AM, Tobias Pape <[hidden email]> wrote: >> >> >> On 26.04.2016, at 07:52, Esteban Lorenzano <[hidden email]> wrote: >> >> > >> >> On 25 Apr 2016, at 23:57, Frank Shearar <[hidden email]> wrote: >> >> >> >> On 23 April 2016 at 10:01, Eliot Miranda <[hidden email]> wrote: >> >> >> >> Hi All, >> >> >> >> one very important question is what are the names of the top level git repository and sub modules? Before you suggest something please check that the name isn't already used on github. >> >> >> >> Here are some suggestions >> >> >> >> http://cogvm.github.io/.com >> >> http://backtothefuture.github.io/.com >> >> https://opensmalltalkvm.github.io/com >> >> >> >> >> >> _,,,^..^,,,_ (phone) >> >> >> >> FWIW I'd go with "cogvm". Short, sweet, to the point. >> > >> > +1 >> >> That would imply to ditch the interpreter vm altogether. >> so -0 from me… > > That's not the intention. I thought so. My statement might have been a bit succinct. I'd should have written "This name would sound as if it implied that we ditched..." > What we need is some effort to integrate the ContextInterpreter back into VMMaker.oscog. David doesn't have the time. The Interpreter in VMMaker.oscog is both ahead and behind the VMMaker Interpreter. I thought so. > The VMMaker.oscog one has Andreas' profiler improvements, but it hasn't been refactored to not inherit from ObjectMemory and and fixes that have been applied to VMMaker's Interpreter could do with being integrated. But it's not a hinge join, just not one I or David have time for. Is there anyone out there with curiosity for the VM who does have some time? > > Tobias, any students you can point at the task? It's a refactoring job and I'll hand hold. I understand that this is important yet tedious work. I could ask around, but I won't promise anything. Yes, I know that the branches should converge again. But how does that solve the naming issue? Would the (Context)Interpreter become another flavor of CogVM? Best regards -Tobias |
Re: Repository name(s) [was Re: [Vm-dev] svn git bridge? ...]
|
|
Hi Tobias, > On May 2, 2016, at 12:12 PM, Tobias Pape <[hidden email]> wrote: > > > Hi Eliot, > >> On 02.05.2016, at 20:54, Eliot Miranda <[hidden email]> wrote: >> >>> Hi Tobias, >>> >>> On Mon, May 2, 2016 at 7:10 AM, Tobias Pape <[hidden email]> wrote: >>> >>> >>>> On 26.04.2016, at 07:52, Esteban Lorenzano <[hidden email]> wrote: >>>> >>>> >>>>> On 25 Apr 2016, at 23:57, Frank Shearar <[hidden email]> wrote: >>>>> >>>>> On 23 April 2016 at 10:01, Eliot Miranda <[hidden email]> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> one very important question is what are the names of the top level git repository and sub modules? Before you suggest something please check that the name isn't already used on github. >>>>> >>>>> Here are some suggestions >>>>> >>>>> http://cogvm.github.io/.com >>>>> http://backtothefuture.github.io/.com >>>>> https://opensmalltalkvm.github.io/com >>>>> >>>>> >>>>> _,,,^..^,,,_ (phone) >>>>> >>>>> FWIW I'd go with "cogvm". Short, sweet, to the point. >>>> >>>> +1 >>> >>> That would imply to ditch the interpreter vm altogether. >>> so -0 from me… >> >> That's not the intention. > > I thought so. My statement might have been a bit succinct. I'd should have written "This name would sound as if it implied that we ditched..." > >> What we need is some effort to integrate the ContextInterpreter back into VMMaker.oscog. David doesn't have the time. The Interpreter in VMMaker.oscog is both ahead and behind the VMMaker Interpreter. > > I thought so. > >> The VMMaker.oscog one has Andreas' profiler improvements, but it hasn't been refactored to not inherit from ObjectMemory and and fixes that have been applied to VMMaker's Interpreter could do with being integrated. But it's not a hinge join, just not one I or David have time for. Is there anyone out there with curiosity for the VM who does have some time? >> >> Tobias, any students you can point at the task? It's a refactoring job and I'll hand hold. > > I understand that this is important yet tedious work. I could ask around, but I won't promise anything. > > Yes, I know that the branches should converge again. > But how does that solve the naming issue? Would the (Context)Interpreter become another flavor of CogVM? Yes. Since it would be able to use Spur that wouldn't be theft, more an exchange :-) > > Best regards > -Tobias > |
Re: Repository name(s) [was Re: [Vm-dev] svn git bridge? ...]
|
|
On Mon, May 02, 2016 at 04:27:11PM -0700, Eliot Miranda wrote: > > Hi Tobias, > > > On May 2, 2016, at 12:12 PM, Tobias Pape <[hidden email]> wrote: > > > > > > Hi Eliot, > > > >> On 02.05.2016, at 20:54, Eliot Miranda <[hidden email]> wrote: > >> > >>> Hi Tobias, > >>> > >>> On Mon, May 2, 2016 at 7:10 AM, Tobias Pape <[hidden email]> wrote: > >>> > >>> > >>>> On 26.04.2016, at 07:52, Esteban Lorenzano <[hidden email]> wrote: > >>>> > >>>> > >>>>> On 25 Apr 2016, at 23:57, Frank Shearar <[hidden email]> wrote: > >>>>> > >>>>> On 23 April 2016 at 10:01, Eliot Miranda <[hidden email]> wrote: > >>>>> > >>>>> Hi All, > >>>>> > >>>>> one very important question is what are the names of the top level git repository and sub modules? Before you suggest something please check that the name isn't already used on github. > >>>>> > >>>>> Here are some suggestions > >>>>> > >>>>> http://cogvm.github.io/.com > >>>>> http://backtothefuture.github.io/.com > >>>>> https://opensmalltalkvm.github.io/com > >>>>> > >>>>> > >>>>> _,,,^..^,,,_ (phone) > >>>>> > >>>>> FWIW I'd go with "cogvm". Short, sweet, to the point. > >>>> > >>>> +1 > >>> > >>> That would imply to ditch the interpreter vm altogether. > >>> so -0 from me??? > >> > >> That's not the intention. > > > > I thought so. My statement might have been a bit succinct. I'd should have written "This name would sound as if it implied that we ditched..." > > > >> What we need is some effort to integrate the ContextInterpreter back into VMMaker.oscog. David doesn't have the time. The Interpreter in VMMaker.oscog is both ahead and behind the VMMaker Interpreter. > > > > I thought so. > > > >> The VMMaker.oscog one has Andreas' profiler improvements, but it hasn't been refactored to not inherit from ObjectMemory and and fixes that have been applied to VMMaker's Interpreter could do with being integrated. But it's not a hinge join, just not one I or David have time for. Is there anyone out there with curiosity for the VM who does have some time? > >> > >> Tobias, any students you can point at the task? It's a refactoring job and I'll hand hold. > > > > I understand that this is important yet tedious work. I could ask around, but I won't promise anything. > > > > Yes, I know that the branches should converge again. > > But how does that solve the naming issue? Would the (Context)Interpreter become another flavor of CogVM? > > Yes. Since it would be able to use Spur that wouldn't be theft, more an exchange :-) Regarding naming, I think that Eliot's distintion between the traditional "context interpreter" and the "stack interpreter" makes perfect sense. Thus the traditional interpreter VM is ContextInterpreter, and the stack interpreter (upon which the Cog and Spur work is based), is StackInterpreter. Both of these subclass from Interpreter. For the object memory, the corresponding classes are ClassicObjectMemory and NewObjectMemory, both of which inherit from ObjectMemory. The traditional "interpreter VM" is now built from ContextInterpreter and ClassicObjectMemory from the VMMaker trunk repository. A stack interpreter built from that repository will generate its code from StackInterpreter and NewObjectMemory. This configuration does not yet work in the VMMaker trunk branch. I think that it is close to working, but I have been saying that for several years now, so don't trust me on this. My hope is to get to the point where a working stack interpreter can be built from StackInterpreter and NewObjectMemory in VMMaker trunk. If and when that works, we would have a known good code base from which the trunk changes could be back-ported to ("exchanged with"?) the oscog repository for Cog and Spur. Dave |
Re: Repository name(s) [was Re: [Vm-dev] svn git bridge? ...]
|
|
Hi all, On 03.05.2016, at 03:16, David T. Lewis <[hidden email]> wrote: > > On Mon, May 02, 2016 at 04:27:11PM -0700, Eliot Miranda wrote: >> […] >>> Yes, I know that the branches should converge again. >>> But how does that solve the naming issue? Would the (Context)Interpreter become another flavor of CogVM? >> >> Yes. Since it would be able to use Spur that wouldn't be theft, more an exchange :-) > [ Snip things I also agree with ] > My hope is to get to the point where a working stack interpreter can be > built from StackInterpreter and NewObjectMemory in VMMaker trunk. If and > when that works, we would have a known good code base from which the trunk > changes could be back-ported to ("exchanged with"?) the oscog repository > for Cog and Spur. I completely agree with that structure. So my concerns about naming were about the Github repo, or better, organization. I thought a bit and, hey, why not call it VMMaker, after all, its the thing that makes VMs and that name already does things. Here's my idea: /VMMaker/ -- Organization (still availabe) /VMMaker/platform/ -- What now is http://www.squeakvm.org/svn/squeak/trunk/platform or http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/ /VMMaker/tools/ -- helping things, such as mkNamedPrims.sh /VMMaker/Cog/ -- Well, what's necessary to build a Cog VM And later maybe /VMMaker/VMMaker/ -- The Smalltalk source as filetree And maybe even SqueakJS, but that's up to Bert :D What do you think? Best regards -Tobias |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |