Vm-dev June 2017

vm-dev@lists.squeakfoundation.org

32 participants
76 discussions

[OpenSmalltalk/opensmalltalk-vm] 4fe424: Fix int */sqInt * mismatch for Win64 FilePlugin
by GitHub 02 Jun '17

02 Jun '17

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 4fe42439a7bed2f0da7835596781b78b478abfd9 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/4fe42439a7bed2f0da… Author: Nicolas Cellier <nicolas.cellier(a)sirehna.com> Date: 2017-06-02 (Fri, 02 Jun 2017) Changed paths: M platforms/Mac OS/plugins/FilePlugin/sqMacDirectory.c M platforms/Mac OS/vm/Developer/sqMacMinimal.c M platforms/Mac OS/vm/sqMacNSPlugin.c M platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c M platforms/win32/vm/sqWin32Directory.c Log Message: ----------- Fix int */sqInt * mismatch for Win64 FilePlugin While at it, also revise a few potential mismatch for legacy Mac OS (which did not have a 64 bits flavour, but well...)

1 0

Re: [Vm-dev] OSProcess fork issue with Debian built VM
by Max Leske 02 Jun '17

02 Jun '17

> On 2 Jun 2017, at 14:00, vm-dev-request(a)lists.squeakfoundation.org wrote: > > Hey! > > >> +1. I would go further and propose that plugins, other than those which are integral to VM[1], be moved into separate projects and built in their own tree with no references to vm source paths. They should be free to organize their platform-specific and platform-independent code and makefiles. > > why? How many plugins are used that don't ship with the pharo-vm (or squeakvm)? I have to say I like the pharo-vm approach a lot where the VMMaker* packages and generated sources sit next to each other. > > Let's compare two options with the OSProcess timeline at hand > > > What happened: > > * I compile with a new compiler, look at the compiler warning and agree with it > * David Lewis agrees with my analysis and fixes it > ... > * Max runs into a crash > * Max debugs a crash.. hours? days? > * Max involves others > ... > * I have to debug the crash myself.. > * I notice that the fix is not there yet > * I have to wait for someone privileged to regenerate the source (black magic?) > > > My preferred option > > * I compile with a new compiler, look at the compiler warning and agree with it > * David Lewis agrees with my analysis and commits/pushes the fix to mc/ directory > * New VM will be build and regenerates sources on the fly > * Max never runs into the problem (Dancing to "Don't know much") ...Oh what a wonderful world this would be!... > > Let's do it the Smalltalk way? Make simple things simple and complex (allow externally maintained plugins) possible? > > have a nice weekend > > holger

1 0

Re: [Vm-dev] the purpose of CI
by Jakob Reschke 02 Jun '17

02 Jun '17

2017-06-02 1:36 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > On Thu, Jun 1, 2017 at 10:40 AM, Ben Coman <btc(a)openinworld.com> wrote: >> I just want to interject a check everyone's understanding of git >> branches. Although I haven't used SVN, what I've read indicates SVN >> concepts can be hard to shake and git branching is conceptually very >> different from SVN. >> >> The key thing is "a branch in Git is simply a lightweight movable pointer >> to a commit." >> The following article seems particularly useful to help frame our >> discussion... >> https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-Is >> > > The commit is related to a graph of previous commits, right? So a branch > implies a distinct set of commits, right? When one merges from a branch, > the commits on the branch don't get added to the target into which one > merges do they Isn't that the difference between pull and pull -a, that > the former just pulls commits on a single branch while pull -a p;pulls > commits on all branches? Git commits refer to their parent commits (merge commits have more than one parent), but do not store on which branch(es) they are or were on. Since a branch is just a reference (to a commit), you may talk about the commits that are reachable from a branch (it is what you get from "git log branchname"). But this set almost always overlaps with that of other branches because of all the common ancestor commits. Merging a branch adds an additional parent to the to-be-created merge commit. Thus, the commits from the merged branch become reachable from the branch into which you are merging. So, in a way, they do get added to the merge target. pull -a does not "pull on all branches" and does not usually affect the result of the merge at all. "git pull <remote> <branch>" essentially means "git fetch <remote> <branch>", which writes the fetched commits to a temporary reference called FETCH_HEAD, followed by "git merge FETCH_HEAD". The -a stands for --append, is an option for the fetch, and means that instead of overwriting what is in .git/FETCH_HEAD, append the newly fetched commits there. But "git merge FETCH_HEAD" will only use the top commit from that file anyway, so this is kind of pointless for pull. In fact, it might lead to merging the wrong branch or not merging anything at all because the latest fetched commit with -a goes to the end of FETCH_HEAD, not the top. But even if it meant to "pull commits on all branches", why would that be useful? When you work and pull on branch/feature X, why would you want to invoke a merge on an unrelated branch/feature Y? If you wanted to merge more than one upstream branch into your current branch, you would have to name them all when pulling: git pull origin branch1 branch2 ... ...which attempts a merge with (1 + number of unmerged upstream branches named on the command line) parent commits.

1 0

[OpenSmalltalk/opensmalltalk-vm] fe6078: Regenerate Unix OS ProcessPlugin from oscog-dtl.56
by GitHub 01 Jun '17

01 Jun '17

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: fe6078f0fe7dede0f737a485f75a8cd23122718b https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/fe6078f0fe7dede0f7… Author: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> Date: 2017-06-01 (Thu, 01 Jun 2017) Changed paths: M src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c Log Message: ----------- Regenerate Unix OS ProcessPlugin from oscog-dtl.56 Signal number references are one-based, dimension arrays accordingly. Remove unreferenced instance variable and accessor.

1 0

Re: [Vm-dev] [Pharo-dev] please test download for Pharo 6.0
by Eliot Miranda 01 Jun '17

01 Jun '17

Hi Marcus, > On Jun 1, 2017, at 2:36 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 31 May 2017, at 17:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> OK, I quickly tested the Mac 32 and 64 bit versions, installing some code, running unit tests, clicking around. Both are working perfectly. >> >> The Pharo Welcome window with the clickable coloured links and the tabs is particularly nice. >> >> The need to move to /Applications is just one thing, you also have to allow the app to actually run (with my settings, by right clicking on it, and giving permission; but even then it stops the first time and only runs the second time; no big deal for me but it might be confusing for others). >> > > I am looking into signing… but as we did not have it for Pharo5, it should not hold up the release. > > The /Applications thing is related to signing, too. (the container, we should ship it with a signed .dmg). If possible please include the code in opensmalltalk/vm. There are good starting points: In {build.macos32x86,build.macos64x64}/newspeak.cog.spur/installer is code that builds the newspeak .dmg, but does not sign it. There's a Makefile. In {build.macos32x86,build.macos64x64}/common/Makefile.app is code to sign an .app bundle using codesign. The certificate to use is indicated via an environment variable as described in {build.macos32x86,build.macos64x64}/HowToBuild. > > I will look into it for next week, but this is a bit independend of the release.. > > Marcus HTH Eliot

1 0

/image/ .gitignore
by Ben Coman 01 Jun '17

01 Jun '17

Minor tuning of the .gitignore file... I wonder if rather than all these special cases we don't want... /image/*.sum /image/*.tgz /image/coglinux* /image/cogwin /image/Cog.app /image/cogspurlinux* /image/sqlinux* /image/cogspurwin /image/CogSpur.app /image/Squeak.*app /image/Squeak-*-All-in-One.* /image/SqueakDebug.log /image/Squeak3D.log /image/__MACOSX /image/crash.dmp /image/package-cache /image/prefs /image/special-dirs /image/*.zip /image/.*history this could be streamlined by concentrating on the files we do want... /image/* !/image/*.sh !/image/*.st !/image/*.text !/image/README which seems to cover it from reviewing what is left over... $ cd image && ls -F | grep -vE '.sh\*$|.st$|.text$|README' Any objections? cheers -ben

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2017