Vm-dev May 2017

vm-dev@lists.squeakfoundation.org

39 participants
158 discussions

Re: [Vm-dev] [squeak-dev] Error in ImageSegment primitive?
by Max Leske 09 May '17

09 May '17

And of course I forgot the code: | rootCollection numberOfLeaves holder | Transcript open. holder := OrderedCollection new. numberOfLeaves := 1000000. rootCollection := OrderedCollection new. 1 to: numberOfLeaves do: [ :i | | next | next := Object new. holder add: next. rootCollection add: i -> next ]. Transcript show: 'copying roots'; cr. [ | im | im := ImageSegment new copyFromRoots: rootCollection sizeHint: 250000 areUnique: true; state: #active yourself. Transcript show: 'out pointers: ', (im outPointers size asString); cr; show: 'segment: ', (im segment size asString); cr ] on: OutOfMemory do: [ Transcript show: 'failed'; cr; cr. Processor activeProcess terminate ]. Transcript show: 'succeeded'; cr; cr. > On 9 May 2017, at 19:15, vm-dev-request(a)lists.squeakfoundation.org wrote: > > [ Reposting with correct subject. Sorry! ] > > >> On 9 May 2017, at 17:46, vm-dev-request(a)lists.squeakfoundation.org <mailto:vm-dev-request@lists.squeakfoundation.org> <mailto:vm-dev-request@lists.squeakfoundation.org <mailto:vm-dev-request@lists.squeakfoundation.org>> wrote: >> >> Hi Max, >> >>> On May 9, 2017, at 7:30 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com> <mailto:maxleske@gmail.com <mailto:maxleske@gmail.com>>> wrote: >>> >>> Hi Eliot, >>> >>> >>>> On 9 May 2017, at 14:32, vm-dev-request(a)lists.squeakfoundation.org <mailto:vm-dev-request@lists.squeakfoundation.org> <mailto:vm-dev-request@lists.squeakfoundation.org <mailto:vm-dev-request@lists.squeakfoundation.org>> wrote: >>>> >>>> Hi Max, >>>> >>>>> On Sun, May 7, 2017 at 4:24 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com> <mailto:maxleske@gmail.com <mailto:maxleske@gmail.com>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm trying to store an image segment with the latest pharo.cog.spur VM (32 >>>>> bits) but keep failing. The segment should produce a file of around 60 MB. >>>>> With an old V3 VM this is no problem at all. There, the WordArrayForSegment >>>>> instance has a size of 4094179 but with the new VM I always run out of >>>>> space because the primitive returns nil and, therefore, the word array size >>>>> is constantly being increased. >>>>> >>>> >>>> It's been a while since I wrote this code so my understanding has been >>>> coming back in fits and starts. The limitation on the use of the hash bits >>>> field is in referring to "out pointers", objects that the saved segment >>>> refers to, not on objects internal to the segment. So I think it's fixable. >>>> >>>> The hash field is used to map from an object in the heap to its object in >>>> the segment. Right now the mapping is from hash (22 bits) to location in >>>> the segment / 8, and so limits the size of the segment to 500kb. If an >>>> extra level of indirection was added so that hash maps to index in an array >>>> of oops, then the segment could contain up to 4m objects and I think >>>> that'll be large enough for your use. >>>> >>>> If that's still not enough then the al;goriqhm will have to be rewritten to >>>> use the first field of the object in the heap to point to its location in >>>> the segment, and the first field saved alongside. >>>> >>>> So let me know. Would you be happy with a fix that provides up to 4m >>>> objects per segment or would you want to wait for something with a much >>>> higher limit? >>> >>> I've sampled 10000 classes and 10000 model specific classes at random and got a median #byteSizeOfInstance of 60 bytes. For 4m objects that would mean an upper limit of 240 MB file size. That is enough for me at the moment, yes. I currently need around 120 MB (with a safety margin of 15 MB). >>> Not having to watch out for that limit would be nice but my priority is to be able to create and read segments. >> >> Agreed, but that's a bigger rewrite. It would have in common some of the approach taken with the new compactor which also uses the first field, in its case to point to eventual location, while saving the contents of the first field in an array off to the side. >> >> (In Spur all objects, including zero-sized ones, have at least one field so that they can be converted into a forwarding pointer). >> >>> How much time do you think it will take you to make the change? I just need a rough idea so I can plan my work around that. >> >> It shouldn't take more than a day; two at the most. You can help me by setting up a test case (although perhaps I can hack up a quick binary tree, so that might not help as much as I expect). > > I've tried to come up with a test case and have one that doesn't fail... Not sure what I'm missing. The test reports the sizes of the segment and its out pointers. I'm including it here, maybe you can work from that. I'm also appending my hacked version of ImageSegment for Pharo 6 (mainly use of FileSystem instead of FileDirectory). > > I hope that helps. > > Cheers, > Max > >> >> The primitive uses a routine that answers the objects to be written to the segment in an array. The primitive needs to be extended with a word array, let's call it the mapArray, as big as this to hold the indirection from hash field to index in the mapArray in which are held the pointers to locations in the segment data. >> >> It might be just as easy/difficult to use a savedFirstFields array (also one element per object to be copied into the array) and point to location from first field, which would eliminate the upper limit immediately. I'll mull this over while at the DMV; a chore I have to do today. >> >>> Thanks for your help! >>> >>> Cheers, >>> Max >>> >>>> >>>> >>>>> I've built a debug VM and am stepping through the code but I don't have a >>>>> clear understanding of everything that's happening. The failure happens on >>>>> line 46626 of gcc3x-cointerp.c: >>>>> >>>>> newOop = (copy - segStart) / 8; >>>>> if (newOop > (identityHashHalfWordMask())) { >>>>> return PrimErrLimitExceeded; // <--------------- failure >>>>> } >>>>> >>>>> What I don't understand, for example, is why "newOop" is checked against >>>>> "identityHashHalfWordMask()" and not against the segment end ("endSeg"). >>>>> Here's a list of the current values of the variables upon failure: >>>>> >>>>> objOop sqInt 180812096 >>>>> segAddr sqInt 494731288 >>>>> segStart sqInt 461176856 >>>>> endSeg sqInt 815841432 >>>>> bodySize usqInt 64 >>>>> contextSize sqInt 335672448 >>>>> copy sqInt 494731288 >>>>> hash sqInt 0 >>>>> hash1 sqInt 4194302 >>>>> i sqInt 833574680 >>>>> iLimiT sqInt 833574688 >>>>> methodHeader sqInt 1193471 >>>>> newOop sqInt 4194304 >>>>> numMediatedSlots sqInt 833574688 >>>>> numSlots usqInt 14 >>>>> oop sqInt 142640272 >>>>> >>>>> As you can see, "endSeg" would be more than large enough to hold the >>>>> object. Is it possible that there's an error here? >>>>> >>>>> Cheers, >>>>> Max >>>>> >>>>> >>>> >>>> >>>> -- >>>> _,,,^..^,,,_ >>>> best, Eliot

1 0

Re: [Vm-dev] Vm-dev Digest, Vol 131, Issue 31
by Max Leske 09 May '17

09 May '17

> On 9 May 2017, at 17:46, vm-dev-request(a)lists.squeakfoundation.org wrote: > > Hi Max, > >> On May 9, 2017, at 7:30 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> >> Hi Eliot, >> >> >>> On 9 May 2017, at 14:32, vm-dev-request(a)lists.squeakfoundation.org <mailto:vm-dev-request@lists.squeakfoundation.org> wrote: >>> >>> Hi Max, >>> >>>> On Sun, May 7, 2017 at 4:24 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>> I'm trying to store an image segment with the latest pharo.cog.spur VM (32 >>>> bits) but keep failing. The segment should produce a file of around 60 MB. >>>> With an old V3 VM this is no problem at all. There, the WordArrayForSegment >>>> instance has a size of 4094179 but with the new VM I always run out of >>>> space because the primitive returns nil and, therefore, the word array size >>>> is constantly being increased. >>>> >>> >>> It's been a while since I wrote this code so my understanding has been >>> coming back in fits and starts. The limitation on the use of the hash bits >>> field is in referring to "out pointers", objects that the saved segment >>> refers to, not on objects internal to the segment. So I think it's fixable. >>> >>> The hash field is used to map from an object in the heap to its object in >>> the segment. Right now the mapping is from hash (22 bits) to location in >>> the segment / 8, and so limits the size of the segment to 500kb. If an >>> extra level of indirection was added so that hash maps to index in an array >>> of oops, then the segment could contain up to 4m objects and I think >>> that'll be large enough for your use. >>> >>> If that's still not enough then the al;goriqhm will have to be rewritten to >>> use the first field of the object in the heap to point to its location in >>> the segment, and the first field saved alongside. >>> >>> So let me know. Would you be happy with a fix that provides up to 4m >>> objects per segment or would you want to wait for something with a much >>> higher limit? >> >> I've sampled 10000 classes and 10000 model specific classes at random and got a median #byteSizeOfInstance of 60 bytes. For 4m objects that would mean an upper limit of 240 MB file size. That is enough for me at the moment, yes. I currently need around 120 MB (with a safety margin of 15 MB). >> Not having to watch out for that limit would be nice but my priority is to be able to create and read segments. > > Agreed, but that's a bigger rewrite. It would have in common some of the approach taken with the new compactor which also uses the first field, in its case to point to eventual location, while saving the contents of the first field in an array off to the side. > > (In Spur all objects, including zero-sized ones, have at least one field so that they can be converted into a forwarding pointer). > >> How much time do you think it will take you to make the change? I just need a rough idea so I can plan my work around that. > > It shouldn't take more than a day; two at the most. You can help me by setting up a test case (although perhaps I can hack up a quick binary tree, so that might not help as much as I expect). I've tried to come up with a test case and have one that doesn't fail... Not sure what I'm missing. The test reports the sizes of the segment and its out pointers. I'm including it here, maybe you can work from that. I'm also appending my hacked version of ImageSegment for Pharo 6 (mainly use of FileSystem instead of FileDirectory). I hope that helps. Cheers, Max > > The primitive uses a routine that answers the objects to be written to the segment in an array. The primitive needs to be extended with a word array, let's call it the mapArray, as big as this to hold the indirection from hash field to index in the mapArray in which are held the pointers to locations in the segment data. > > It might be just as easy/difficult to use a savedFirstFields array (also one element per object to be copied into the array) and point to location from first field, which would eliminate the upper limit immediately. I'll mull this over while at the DMV; a chore I have to do today. > >> Thanks for your help! >> >> Cheers, >> Max >> >>> >>> >>>> I've built a debug VM and am stepping through the code but I don't have a >>>> clear understanding of everything that's happening. The failure happens on >>>> line 46626 of gcc3x-cointerp.c: >>>> >>>> newOop = (copy - segStart) / 8; >>>> if (newOop > (identityHashHalfWordMask())) { >>>> return PrimErrLimitExceeded; // <--------------- failure >>>> } >>>> >>>> What I don't understand, for example, is why "newOop" is checked against >>>> "identityHashHalfWordMask()" and not against the segment end ("endSeg"). >>>> Here's a list of the current values of the variables upon failure: >>>> >>>> objOop sqInt 180812096 >>>> segAddr sqInt 494731288 >>>> segStart sqInt 461176856 >>>> endSeg sqInt 815841432 >>>> bodySize usqInt 64 >>>> contextSize sqInt 335672448 >>>> copy sqInt 494731288 >>>> hash sqInt 0 >>>> hash1 sqInt 4194302 >>>> i sqInt 833574680 >>>> iLimiT sqInt 833574688 >>>> methodHeader sqInt 1193471 >>>> newOop sqInt 4194304 >>>> numMediatedSlots sqInt 833574688 >>>> numSlots usqInt 14 >>>> oop sqInt 142640272 >>>> >>>> As you can see, "endSeg" would be more than large enough to hold the >>>> object. Is it possible that there's an error here? >>>> >>>> Cheers, >>>> Max >>>> >>>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot

1 0

Re: [Vm-dev] [squeak-dev] Error in ImageSegment primitive?
by Max Leske 09 May '17

09 May '17

Hi Eliot, > On 9 May 2017, at 14:32, vm-dev-request(a)lists.squeakfoundation.org wrote: > > Hi Max, > > On Sun, May 7, 2017 at 4:24 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> Hi, >> >> I'm trying to store an image segment with the latest pharo.cog.spur VM (32 >> bits) but keep failing. The segment should produce a file of around 60 MB. >> With an old V3 VM this is no problem at all. There, the WordArrayForSegment >> instance has a size of 4094179 but with the new VM I always run out of >> space because the primitive returns nil and, therefore, the word array size >> is constantly being increased. >> > > It's been a while since I wrote this code so my understanding has been > coming back in fits and starts. The limitation on the use of the hash bits > field is in referring to "out pointers", objects that the saved segment > refers to, not on objects internal to the segment. So I think it's fixable. > > The hash field is used to map from an object in the heap to its object in > the segment. Right now the mapping is from hash (22 bits) to location in > the segment / 8, and so limits the size of the segment to 500kb. If an > extra level of indirection was added so that hash maps to index in an array > of oops, then the segment could contain up to 4m objects and I think > that'll be large enough for your use. > > If that's still not enough then the al;goriqhm will have to be rewritten to > use the first field of the object in the heap to point to its location in > the segment, and the first field saved alongside. > > So let me know. Would you be happy with a fix that provides up to 4m > objects per segment or would you want to wait for something with a much > higher limit? I've sampled 10000 classes and 10000 model specific classes at random and got a median #byteSizeOfInstance of 60 bytes. For 4m objects that would mean an upper limit of 240 MB file size. That is enough for me at the moment, yes. I currently need around 120 MB (with a safety margin of 15 MB). Not having to watch out for that limit would be nice but my priority is to be able to create and read segments. How much time do you think it will take you to make the change? I just need a rough idea so I can plan my work around that. Thanks for your help! Cheers, Max > > >> I've built a debug VM and am stepping through the code but I don't have a >> clear understanding of everything that's happening. The failure happens on >> line 46626 of gcc3x-cointerp.c: >> >> newOop = (copy - segStart) / 8; >> if (newOop > (identityHashHalfWordMask())) { >> return PrimErrLimitExceeded; // <--------------- failure >> } >> >> What I don't understand, for example, is why "newOop" is checked against >> "identityHashHalfWordMask()" and not against the segment end ("endSeg"). >> Here's a list of the current values of the variables upon failure: >> >> objOop sqInt 180812096 >> segAddr sqInt 494731288 >> segStart sqInt 461176856 >> endSeg sqInt 815841432 >> bodySize usqInt 64 >> contextSize sqInt 335672448 >> copy sqInt 494731288 >> hash sqInt 0 >> hash1 sqInt 4194302 >> i sqInt 833574680 >> iLimiT sqInt 833574688 >> methodHeader sqInt 1193471 >> newOop sqInt 4194304 >> numMediatedSlots sqInt 833574688 >> numSlots usqInt 14 >> oop sqInt 142640272 >> >> As you can see, "endSeg" would be more than large enough to hold the >> object. Is it possible that there's an error here? >> >> Cheers, >> Max >> >> > > > -- > _,,,^..^,,,_ > best, Eliot

2 1

prespur vm for sierra
by Tudor Girba 09 May '17

09 May '17

Hi, I have a demo image coming from a pre-Spur era, and I just realized that I cannot run the old VM on Sierra. Is there a version that I can use for this? Cheers, Doru -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

3 3

Mail was down, sorry ¯\_(ツ)_/¯
by Tobias Pape 09 May '17

09 May '17

Remaining mails are being processed atm. From the engine room -Tobias

1 0

[OpenSmalltalk/opensmalltalk-vm] 5fb5c0: SqueakSSL v3: With support for verifiation on macO...
by GitHub 09 May '17

09 May '17

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 5fb5c090f21e6a95a1e550a1ff39bfc0dcc9ea7d https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/5fb5c090f21e6a95a1… Author: Tobias Pape <tobias(a)netshed.de> Date: 2017-05-09 (Tue, 09 May 2017) Changed paths: M platforms/Cross/plugins/SqueakSSL/SqueakSSL.h M platforms/iOS/plugins/SqueakSSL/sqMacSSL.c Log Message: ----------- SqueakSSL v3: With support for verifiation on macOS

1 0

Re: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] command line arguments use single dash prefix but also accept doubledash (#136)
by Eliot Miranda 09 May '17

09 May '17

IIABDFI Esteban rewrote the code that use -- for Pharo, preserving - for Squeak. What's the problem?? _,,,^..^,,,_ (phone) > On May 7, 2017, at 8:50 AM, Ben Coman <notifications(a)github.com> wrote: > > @bencoman requested changes on this pull request. > > Can we have some discussion on [vm-dev] about the flexibility of Squeakers to use double-hyphen options as default? > > In platforms/unix/vm/sqUnixMain.c: > > > @@ -1467,7 +1464,8 @@ static int vm_parseArgument(int argc, char **argv) > > /* vm arguments */ > > - if (!strcmp(argv[0], VMOPTION("help"))) { usage(); return 1; } > + if (!strcmp(argv[0], VMOPTION("help"))) { usage(0); /*NOTREACHED*/} > Would it be better to shift the exit() out of usage(), so that real code affection execution flow is used here rather than a comment. i.e. here... { usage(); exit(0) } ?? > > In platforms/unix/vm/sqUnixMain.c: > > > @@ -1721,7 +1719,7 @@ static void usage(void) > printf("\nAvailable drivers:\n"); > for (m= modules; m->next; m= m->next) > printf(" %s\n", m->name); > - exit(1); > + exit(exitValue); > Refactor the exit() out to the caller ?? > > In platforms/unix/vm/sqUnixMain.c: > > > @@ -1819,7 +1817,8 @@ static void parseArguments(int argc, char **argv) > if (n == 0) /* option not recognised */ > { > fprintf(stderr, "unknown option: %s\n", argv[0]); > - usage(); > + usage(1); > + /*NOTREACHED*/ > Same as above, refactor exit out of usage() ? i.e. here... > usage(); > exit(1) > > In platforms/unix/vm/sqUnixMain.c: > > > { > struct SqModule *m= 0; > printf("Usage: %s [<option>...] [<imageName> [<argument>...]]\n", argVec[0]); > printf(" %s [<option>...] -- [<argument>...]\n", argVec[0]); > + printf("options begin with single -, but -- prefix is silently accepted\n"); > The problem is that single-hyphen default is then what is advised by --help. Why isn't it preferable to conform to Unix conventions [1] "The GNU double-hyphen option leader was chosen so that traditional single-letter options and GNU-style keyword options could be unambiguously mixed on the same command line. " > [1] http://www.catb.org/~esr/writings/taoup/html/ch10s05.html > > The single-hyphen could be silently accepted for backward compatibility. Maybe better would be a deprecated message, but perhaps that could adversely affect existing scripts(?). > > How do Squeakers feel about that? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. >

3 4

Re: [Vm-dev] [squeak-dev] Error in ImageSegment primitive?
by Eliot Miranda 09 May '17

09 May '17

Hi Max, On Sun, May 7, 2017 at 4:24 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi, > > I'm trying to store an image segment with the latest pharo.cog.spur VM (32 > bits) but keep failing. The segment should produce a file of around 60 MB. > With an old V3 VM this is no problem at all. There, the WordArrayForSegment > instance has a size of 4094179 but with the new VM I always run out of > space because the primitive returns nil and, therefore, the word array size > is constantly being increased. > It's been a while since I wrote this code so my understanding has been coming back in fits and starts. The limitation on the use of the hash bits field is in referring to "out pointers", objects that the saved segment refers to, not on objects internal to the segment. So I think it's fixable. The hash field is used to map from an object in the heap to its object in the segment. Right now the mapping is from hash (22 bits) to location in the segment / 8, and so limits the size of the segment to 500kb. If an extra level of indirection was added so that hash maps to index in an array of oops, then the segment could contain up to 4m objects and I think that'll be large enough for your use. If that's still not enough then the al;goriqhm will have to be rewritten to use the first field of the object in the heap to point to its location in the segment, and the first field saved alongside. So let me know. Would you be happy with a fix that provides up to 4m objects per segment or would you want to wait for something with a much higher limit? > I've built a debug VM and am stepping through the code but I don't have a > clear understanding of everything that's happening. The failure happens on > line 46626 of gcc3x-cointerp.c: > > newOop = (copy - segStart) / 8; > if (newOop > (identityHashHalfWordMask())) { > return PrimErrLimitExceeded; // <--------------- failure > } > > What I don't understand, for example, is why "newOop" is checked against > "identityHashHalfWordMask()" and not against the segment end ("endSeg"). > Here's a list of the current values of the variables upon failure: > > objOop sqInt 180812096 > segAddr sqInt 494731288 > segStart sqInt 461176856 > endSeg sqInt 815841432 > bodySize usqInt 64 > contextSize sqInt 335672448 > copy sqInt 494731288 > hash sqInt 0 > hash1 sqInt 4194302 > i sqInt 833574680 > iLimiT sqInt 833574688 > methodHeader sqInt 1193471 > newOop sqInt 4194304 > numMediatedSlots sqInt 833574688 > numSlots usqInt 14 > oop sqInt 142640272 > > As you can see, "endSeg" would be more than large enough to hold the > object. Is it possible that there's an error here? > > Cheers, > Max > > -- _,,,^..^,,,_ best, Eliot

1 0

How should one implement a custom window color for a custom window?
by Eliot Miranda 08 May '17

08 May '17

Hi Marcel, Hi All, at one point I had implemented custom window colors for the VM simulator window thusly: InterpreterPrimitives class>>initialize "Initialize the window color. This is probably Squeak-specific, so..." [Preferences setWindowColorFor: #cogVirtualMachineSimulatorWindowColor to: (Color colorFrom: InterpreterPrimitives windowColorSpecification brightColor)] on: Error do: [:ex| Transcript show: 'Failed to set window color preference in ', thisContext method methodReference asString] SimulatorMorphicModel class>>registerWindowColor (Preferences windowColorFor: self name) = Color white ifTrue: [ Preferences setWindowColorFor: self name to: (Color colorFrom: self windowColorSpecification brightColor) ]. This approach is now deprecated, causing the load script to protest. But the deprecation message isn't helpful. The setter setWindowColorFor:to: just says the method is deprecated, not suggesting any alternative. The getter Preferences class>>#windowColorFor: just says 'Use Model >> #customWindowColor', but the method isn't implemented in any class. Where's an example of the right way to do it? Could the deprecation warnings be more informative? thanks _,,,^..^,,,_ best, Eliot

1 0

Downloading from binary via curl
by Eliot Miranda 08 May '17

08 May '17

Hi All, I want to be able to answer Max's message below with "run this script to build a VMMaker image", but so far I'm unable to download a VM from binary via curl (the default downloader on Mac OS X). If I try e.g. $ curl -k -o cog_macos32x86_squeak.cog.spur_201705051953.tar.gz https://dl.bintray.com/opensmalltalk/vm/cog_macos32x86_squeak.cog.spur_2017… I get an empty .tar.gz If I use wget (something I've built and installed myself): wget -o cog_macos32x86_squeak.cog.spur_201705051953.tar.gz https://dl.bintray.com/opensmalltalk/vm/cog_macos32x86_squeak.cog.spur_2017… I get $ cat cog_macos32x86_squeak.cog.spur_201705051953.tar.gz --2017-05-08 11:56:10-- https://dl.bintray.com/opensmalltalk/vm/cog_macos32x86_squeak.cog.spur_2017… Resolving dl.bintray.com... 75.126.118.188 Connecting to dl.bintray.com|75.126.118.188|:443... connected. ERROR: cannot verify dl.bintray.com's certificate, issued by `/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3': Unable to locally verify the issuer's authority. To connect to dl.bintray.com insecurely, use `--no-check-certificate'. Unable to establish SSL connection. And if I use --no-check-certificate I still fail: $ wget --no-check-certificate -o cog_macos32x86_squeak.cog.spur_201705051953.tar.gz https://dl.bintray.com/opensmalltalk/vm/cog_macos32x86_squeak.cog.spur_2017… $ cat cog_macos32x86_squeak.cog.spur_201705051953.tar.gz --2017-05-08 11:58:30-- https://dl.bintray.com/opensmalltalk/vm/cog_macos32x86_squeak.cog.spur_2017… Resolving dl.bintray.com... 75.126.118.188 Connecting to dl.bintray.com|75.126.118.188|:443... connected. WARNING: cannot verify dl.bintray.com's certificate, issued by `/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3': Unable to locally verify the issuer's authority. HTTP request sent, awaiting response... 302 Location: https://akamai.bintray.com/c6/c6ba54ff93f202c24e6008cb5c8b49c803b4ac21b4364… [following] --2017-05-08 11:58:31-- https://akamai.bintray.com/c6/c6ba54ff93f202c24e6008cb5c8b49c803b4ac21b4364… Resolving akamai.bintray.com... 104.68.118.43 Connecting to akamai.bintray.com|104.68.118.43|:443... connected. WARNING: cannot verify akamai.bintray.com's certificate, issued by `/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4': Unable to locally verify the issuer's authority. HTTP request sent, awaiting response... 200 OK Length: 1220748 (1.2M) [application/x-www-form-urlencoded] c6ba54ff93f202c24e6008cb5c8b49c803b4ac21b43646fc1c91756d6c985b19?__gda__=exp=1494270631~hmac=3fe7f593f3440ace34e3c013ab7119d52093ba1672a32f14f1747e3e7a4e0235&response-content-disposition=attachment;filename="cog_macos32x86_squeak.cog.spur_201705051953.tar.gz"&response-content-type=application%2Fx-www-form-urlencoded&requestInfo=U2FsdGVkX18Y_MJoYGQOYlat_mYoKMgk2XAwj9mM83g2sVlybJ4IVHj2U_7RPrccLSntxKjKu84Nw9tuDyVRF1bks0b9U_BjqCvXL9pfJZu_Z4BHUULx0GBuM5nr-oQndxXSWmK6CFB5zlERWr16NcVwm6K418muvWavbqgHjmI: File name too long Cannot write to `c6ba54ff93f202c24e6008cb5c8b49c803b4ac21b43646fc1c91756d6c985b19?__gda__=exp=1494270631~hmac=3fe7f593f3440ace34e3c013ab7119d52093ba1672a32f14f1747e3e7a4e0235&response-content-disposition=attachment;filename="cog_macos32x86_squeak.cog.spur_201705051953.tar.gz"&response-content-type=application%2Fx-www-form-urlencoded&requestInfo=U2FsdGVkX18Y_MJoYGQOYlat_mYoKMgk2XAwj9mM83g2sVlybJ4IVHj2U_7RPrccLSntxKjKu84Nw9tuDyVRF1bks0b9U_BjqCvXL9pfJZu_Z4BHUULx0GBuM5nr-oQndxXSWmK6CFB5zlERWr16NcVwm6K418muvWavbqgHjmI' (Undefined error: 0). On Sun, May 7, 2017 at 4:24 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi, > > I'm trying to store an image segment with the latest pharo.cog.spur VM (32 > bits) but keep failing. The segment should produce a file of around 60 MB. > With an old V3 VM this is no problem at all. There, the WordArrayForSegment > instance has a size of 4094179 but with the new VM I always run out of > space because the primitive returns nil and, therefore, the word array size > is constantly being increased. > > I've built a debug VM and am stepping through the code but I don't have a > clear understanding of everything that's happening. The failure happens on > line 46626 of gcc3x-cointerp.c: > > newOop = (copy - segStart) / 8; > if (newOop > (identityHashHalfWordMask())) { > return PrimErrLimitExceeded; // <--------------- failure > } > > What I don't understand, for example, is why "newOop" is checked against > "identityHashHalfWordMask()" and not against the segment end ("endSeg"). > Here's a list of the current values of the variables upon failure: > > objOop sqInt 180812096 > segAddr sqInt 494731288 > segStart sqInt 461176856 > endSeg sqInt 815841432 > bodySize usqInt 64 > contextSize sqInt 335672448 > copy sqInt 494731288 > hash sqInt 0 > hash1 sqInt 4194302 > i sqInt 833574680 > iLimiT sqInt 833574688 > methodHeader sqInt 1193471 > newOop sqInt 4194304 > numMediatedSlots sqInt 833574688 > numSlots usqInt 14 > oop sqInt 142640272 > > As you can see, "endSeg" would be more than large enough to hold the > object. Is it possible that there's an error here? > > Cheers, > Max > > -- _,,,^..^,,,_ best, Eliot

1 1

← Newer
1
...
9
10
11
12
13
14
15
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2017