Something in the update process damages the background
Locked
12
12
 
|
Is there a best-practice for fiddling with ReleaseBuilderForXdotY ? I downloaded the latest trunk image so I could look at the recent background image issue and, after running ReleaseBuilderFor4dot5 class>>prepareNewBuild discovered that it uses MCHttpRepository to upload to the source.squeak.org/trunk. I was going to play around with MCFileBasedRepository to save locally, but decided to ask the list first. Also, my apologies if I accidently clobbered /trunk thx. |
|
|
On 12 September 2013 14:00, gettimothy <[hidden email]> wrote:
> Is there a best-practice for fiddling with ReleaseBuilderForXdotY ? > > I downloaded the latest trunk image so I could look at the recent background > image issue and, after running ReleaseBuilderFor4dot5 class>>prepareNewBuild > discovered that it uses MCHttpRepository to upload to the > source.squeak.org/trunk. > > I was going to play around with MCFileBasedRepository to save locally, but > decided to ask the list first. > > Also, my apologies if I accidently clobbered /trunk There is no ReleaseBuilderForXdotY. There is only ReleaseBuilder. (Imagine that in a voice from Ghostbusters.) You probably won't be able to clobber trunk. Or, if you did, it's an administrator who's to blame, because only a few folk have commit rights to Trunk. (Unlike Inbox, which is world-writable.) frank |
Re: Something in the update process damages the background
|
|
In reply to this post by Karl Ramberg
On Thu, Sep 12, 2013 at 5:31 AM, karl ramberg <[hidden email]> wrote:
> > > On Thu, Sep 12, 2013 at 4:13 AM, Chris Muller <[hidden email]> wrote: >> >> On Wed, Sep 11, 2013 at 2:52 PM, karl ramberg <[hidden email]> >> wrote: >> > I agree with this. Look for a user set background, if nil do default >> > fill, >> >> I don't understand your proposal. The background just _is_ whatever >> it is. We set it during the release process. When someone downloads >> a release image, they either "set the background" to a color, >> gradient, pattern, or bitmap of their choice or, they don't. How are >> you going to "look for a user set background?" When would such a >> thing be done? Upon loading Morphic? Why? Why not just leave it as >> is ? > > > I'm not able to check right now but isn't the background held in a instance > variable ? > If the current background instance is lost or corrupt, the defaultBackground > should be used. > > It would be nice to have all setting like this as part of a theme setting > one could file out and import into other images. It already is -- see the Preference Browser "save to disk" and "load from disk". > I don't think this should be a ReleaseBuilder setting. While I wish a "transparent" background was supported, it's not -- every image has SOME kind of background. Unless we want it to be... random? then I can't see how setting the background wouldn't be part of the release process. |
Re: Something in the update process damages the background
|
|
On 12 September 2013 16:15, Chris Muller <[hidden email]> wrote:
> On Thu, Sep 12, 2013 at 5:31 AM, karl ramberg <[hidden email]> wrote: >> >> >> On Thu, Sep 12, 2013 at 4:13 AM, Chris Muller <[hidden email]> wrote: >>> >>> On Wed, Sep 11, 2013 at 2:52 PM, karl ramberg <[hidden email]> >>> wrote: >>> > I agree with this. Look for a user set background, if nil do default >>> > fill, >>> >>> I don't understand your proposal. The background just _is_ whatever >>> it is. We set it during the release process. When someone downloads >>> a release image, they either "set the background" to a color, >>> gradient, pattern, or bitmap of their choice or, they don't. How are >>> you going to "look for a user set background?" When would such a >>> thing be done? Upon loading Morphic? Why? Why not just leave it as >>> is ? >> >> >> I'm not able to check right now but isn't the background held in a instance >> variable ? >> If the current background instance is lost or corrupt, the defaultBackground >> should be used. >> >> It would be nice to have all setting like this as part of a theme setting >> one could file out and import into other images. > > It already is -- see the Preference Browser "save to disk" and "load from disk". > >> I don't think this should be a ReleaseBuilder setting. > > While I wish a "transparent" background was supported, it's not -- > every image has SOME kind of background. Unless we want it to be... > random? then I can't see how setting the background wouldn't be part > of the release process. Setting the background should _always_ be part of the release process, and _never_ part of simply updating a package. I do think we're all starting to violently agree. frank |
Re: Something in the update process damages the background
|
|
It's not that the actual background is so terribly important, though it is kinda in your face, as the principal of having settable preferences and a way to save/reload them that doesn't annoy.
For any setting where there is a default and a way to personalise , there ought to be a) an easy way to return to the default b) when saving your settings any personal choice should be recorded c) when saving your settings *only* those you changed should be recorded d) when loading your saved settings all your choices that are still relevant should be loaded d) when loading your saved setting *only* the ones you changed should be installed e) it would be really nice to be able to merge-load preferences like we merge mc changes so settings can be shared Right now the background does not seem to follow any of the above (but I've been wrong before - http://www.youtube.com/watch?v=fHJvrnCmxd0) and i would imagine other settings are equally guilty. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: DNPG: Do Not Pass Go |
|
|
In reply to this post by Frank Shearar-3
Good news on the trunk! I am confused by what you mean by 'There is no ReleaseBuilderForXdotY'. I went here: http://ftp.squeak.org/trunk/ Downloaded the .image and .change, then copied over an existing cogvm, sources and stuff, fired up and browsing ReleaseBuilder --> show hierarchy yields: ProtoObject #() Object #() Behavior #('superclass' 'methodDict' 'format') ClassDescription #('instanceVariables' 'organization') Class #('subclasses' 'name' 'classPool' 'sharedPools' 'environment' 'category') ProtoObject class #() Object class #() ReleaseBuilder class #() ReleaseBuilderDeveloper class #() ReleaseBuilderFor3dot10 class #('current') ReleaseBuilderFor3dot11 class #() ReleaseBuilderFor4dot3 class #() ReleaseBuilderFor4dot4 class #() ReleaseBuilderFor4dot5 class #() ReleaseBuilderNihongo class #() ReleaseBuilderSqueakland class #() Since this is the 4.5 release series, I was poking around in the ReleaseBuilderFor4.5 to see if I could solve the image issue for you guys. ReleaseBuilderFor4dot5 class>>prepareNewBuild hung when it tried to put my (ahem) work up on trunk. It was then, I thought I should modify ReleaseBuilderFor4dot5>>releaseRepository to store my work locally. If people commonly do that, I would like to mirror that style to keep things consistent. On 12 September 2013 14:00, gettimothy <[hidden email]> wrote: |
|
|
Right. That version's somewhere around 300 commits behind Trunk. After
you update the image (open the Squeak menu in the docking bar at the top, on the far left), you will find only ReleaseBuilder. You always have local storage available, in the form of an MCCacheRepository pointing to the /your/image/path/package-cache/ directory. We really ought to push out a more up-to-date image, which requires me to finish finding out why the continuous integration update-image.st script is broken. frank On 12 September 2013 17:22, gettimothy <[hidden email]> wrote: > Good news on the trunk! > > I am confused by what you mean by 'There is no ReleaseBuilderForXdotY'. > > I went here: http://ftp.squeak.org/trunk/ > > Downloaded the .image and .change, then copied over an existing cogvm, > sources and stuff, fired up and browsing > ReleaseBuilder --> show hierarchy yields: > > ProtoObject #() > Object #() > Behavior #('superclass' 'methodDict' 'format') > ClassDescription #('instanceVariables' 'organization') > Class #('subclasses' 'name' 'classPool' 'sharedPools' > 'environment' 'category') > ProtoObject class #() > Object class #() > > ReleaseBuilder class #() > ReleaseBuilderDeveloper class #() > ReleaseBuilderFor3dot10 class #('current') > ReleaseBuilderFor3dot11 class #() > ReleaseBuilderFor4dot3 class #() > ReleaseBuilderFor4dot4 class #() > ReleaseBuilderFor4dot5 class #() > ReleaseBuilderNihongo class #() > ReleaseBuilderSqueakland class #() > > Since this is the 4.5 release series, I was poking around in the > ReleaseBuilderFor4.5 to see if I could solve the image issue for you guys. > ReleaseBuilderFor4dot5 class>>prepareNewBuild hung when it tried to put my > (ahem) work up on trunk. > > It was then, I thought I should modify > ReleaseBuilderFor4dot5>>releaseRepository to store my work locally. > > If people commonly do that, I would like to mirror that style to keep things > consistent. > > > > > > > ---- On Thu, 12 Sep 2013 07:21:23 -0700 Frank > Shearar<[hidden email]> wrote ---- > > On 12 September 2013 14:00, gettimothy <[hidden email]> wrote: >> Is there a best-practice for fiddling with ReleaseBuilderForXdotY ? >> >> I downloaded the latest trunk image so I could look at the recent >> background >> image issue and, after running ReleaseBuilderFor4dot5 >> class>>prepareNewBuild >> discovered that it uses MCHttpRepository to upload to the >> source.squeak.org/trunk. >> >> I was going to play around with MCFileBasedRepository to save locally, but >> decided to ask the list first. >> >> Also, my apologies if I accidently clobbered /trunk > > There is no ReleaseBuilderForXdotY. There is only ReleaseBuilder. > (Imagine that in a voice from Ghostbusters.) > > You probably won't be able to clobber trunk. Or, if you did, it's an > administrator who's to blame, because only a few folk have commit > rights to Trunk. (Unlike Inbox, which is world-writable.) > > frank > > > > > |
|
|
Awesome. Thank you. I did a google on the Squeak Release process and found a thread (by you) here: http://forum.world.st/Squeak-release-process-td4640158.html Did that ever come to fruition? Would a HelpBrowser entry be helpful? (I will write it if so, and the information is available) The goal, is that newbs like me can get the release environment running locally and mash around a bit without bothering the experts too much. thx. Right. That version's somewhere around 300 commits behind Trunk. After |
|
|
That's from quite a while ago! Yes, it worked out, and I ended up
volunteering/being volunteered to get 4.4 released. You can find the notes for the current release cycle at http://wiki.squeak.org/squeak/6189. I'm certainly not _opposed_ to documenting the release process in the HelpBrowser. Some parts of the release process are of necessity outside the image, but that's OK. I'm a bit confused by the way you talk about the release process though. It's not something people need to run, usually. frank On 12 September 2013 19:15, gettimothy <[hidden email]> wrote: > Awesome. > > Thank you. > > I did a google on the Squeak Release process and found a thread (by you) > here: http://forum.world.st/Squeak-release-process-td4640158.html > > Did that ever come to fruition? Would a HelpBrowser entry be helpful? (I > will write it if so, and the information is available) > > The goal, is that newbs like me can get the release environment running > locally and mash around a bit without bothering the experts too much. > > thx. > > > > > ---- On Thu, 12 Sep 2013 10:31:41 -0700 Frank > Shearar<[hidden email]> wrote ---- > > Right. That version's somewhere around 300 commits behind Trunk. After > you update the image (open the Squeak menu in the docking bar at the > top, on the far left), you will find only ReleaseBuilder. > > You always have local storage available, in the form of an > MCCacheRepository pointing to the /your/image/path/package-cache/ > directory. > > We really ought to push out a more up-to-date image, which requires me > to finish finding out why the continuous integration update-image.st > script is broken. > > frank > > On 12 September 2013 17:22, gettimothy <[hidden email]> wrote: >> Good news on the trunk! >> >> I am confused by what you mean by 'There is no ReleaseBuilderForXdotY'. >> >> I went here: http://ftp.squeak.org/trunk/ >> >> Downloaded the .image and .change, then copied over an existing cogvm, >> sources and stuff, fired up and browsing >> ReleaseBuilder --> show hierarchy yields: >> >> ProtoObject #() >> Object #() >> Behavior #('superclass' 'methodDict' 'format') >> ClassDescription #('instanceVariables' 'organization') >> Class #('subclasses' 'name' 'classPool' 'sharedPools' >> 'environment' 'category') >> ProtoObject class #() >> Object class #() >> >> ReleaseBuilder class #() >> ReleaseBuilderDeveloper class #() >> ReleaseBuilderFor3dot10 class #('current') >> ReleaseBuilderFor3dot11 class #() >> ReleaseBuilderFor4dot3 class #() >> ReleaseBuilderFor4dot4 class #() >> ReleaseBuilderFor4dot5 class #() >> ReleaseBuilderNihongo class #() >> ReleaseBuilderSqueakland class #() >> >> Since this is the 4.5 release series, I was poking around in the >> ReleaseBuilderFor4.5 to see if I could solve the image issue for you guys. >> ReleaseBuilderFor4dot5 class>>prepareNewBuild hung when it tried to put my >> (ahem) work up on trunk. >> >> It was then, I thought I should modify >> ReleaseBuilderFor4dot5>>releaseRepository to store my work locally. >> >> If people commonly do that, I would like to mirror that style to keep >> things >> consistent. >> >> >> >> >> >> >> ---- On Thu, 12 Sep 2013 07:21:23 -0700 Frank >> Shearar<[hidden email]> wrote ---- >> >> On 12 September 2013 14:00, gettimothy <[hidden email]> wrote: >>> Is there a best-practice for fiddling with ReleaseBuilderForXdotY ? >>> >>> I downloaded the latest trunk image so I could look at the recent >>> background >>> image issue and, after running ReleaseBuilderFor4dot5 >>> class>>prepareNewBuild >>> discovered that it uses MCHttpRepository to upload to the >>> source.squeak.org/trunk. >>> >>> I was going to play around with MCFileBasedRepository to save locally, >>> but >>> decided to ask the list first. >>> >>> Also, my apologies if I accidently clobbered /trunk >> >> There is no ReleaseBuilderForXdotY. There is only ReleaseBuilder. >> (Imagine that in a voice from Ghostbusters.) >> >> You probably won't be able to clobber trunk. Or, if you did, it's an >> administrator who's to blame, because only a few folk have commit >> rights to Trunk. (Unlike Inbox, which is world-writable.) >> >> frank >> >> >> >> >> > > > > > |
|
|
I want to get to where I can write a plug-in for the VM, have the VM see it and use it, then build a release with it. (locally, of course) One motivation is urrent issues with I recently posted on regarding VNC client on squeak primitiive error SSL tanking on WebClient The bug on Squeak4.4 and 4.5 where modifying a comment and attempting to save it throws a system level exception. These are all things I want to use for projects I am working on and I don't know how to fix them. t That's from quite a while ago! Yes, it worked out, and I ended up |
|
|
Tim,
On 9/12/13 5:50 PM, gettimothy wrote:
This doesn't depend on mastering the release process. "Release" here just means prettying up the image in certain ways to make it palatable to new users. The image you are using right now is fine for developing a plugin and for a local release. You've mentioned this one before, but I never saw any details. Are others aware of this issue? Cheers,
|
|
|
When I first ran into the issue, I saw some talk on it. A search for "Squeak4.5 remoteString past end of file error" will bring up references. The error thrown is in:
The immediate callstack below looks like this:
This is from Squeak4.5-12568.zip that I downloaded this afternoon from ftp://ftp.squeak.org/trunk/ (Note: same with the Squeak4.5-12641.zip that is there--I just tested it while typing this email) I am running on Slackware Linux 64 with 32 bit compatability libs installed. The same image works fine when I boot do my dos partition and run it there. t.
|
|
|
Tim,
I does not appear to be an image problem. Frank suggested this: On 4/26/13 6:17 AM, Frank Shearar wrote
Some thought this not the nicest solution, but it would be useful to know if the image you are using has had this added or if you can add it and try.For those not following the Pharo list, it looks like the root cause is that the glibc in Ubuntu 13.04 doesn't immediately write new content out to the file. Thus you can "write" to the file, and then read from the file, only your RemoteString starts off the end of the file. The fix is to make WriteStream >> #nextPutChunk: call "self flush". I've pushed a 4.5 fix to trunk, but have not yet done the same for the 4.4 and 4.3 update streams. frank Frank did add this later after retracting the squeak change That's correct: patching #nextChunkPut: almost certainly masks the underlying problem, and the more experience Squeakers strongly suggested I revert. I'll post updates as they happen.If I were experiencing this problem I suspect I'd make the fix and move on rather than re-experience the problem over and over. Also see if your Linux distro has fixed it on their end. Cheers, Bob On 9/12/13 6:17 PM, gettimothy wrote:
|
|
|
In reply to this post by Bob Arning-2
Thanks for the heads up that the plugin/VM process is irrelevant to the Release process. That clarifies things a bit. I did not mention, because I am new here--and pie-in-the-sky is annoying when you are busy-- that I had an idea for something along the lines of Twitter Bootstrap's customize page: http://getbootstrap.com/2.3.2/customize.html I do not have time to code it now (maybe never) but as an end user, I would love something like that when downloading Squeak. Basically dev takes care of core-dev and then people who have an itch to scratch or interest could provide the 'sugar' for niche interests in the form of release profiles. For example, the recent discussion on Worlds by N.Suslov. From a Seaside callback, collect the options for needed for the end user, feed the results to ReleaseBuilder, store the (and cache) result and email with link when ready to download. With the knowledge of the release process, I could build that. Cordially, t
|
|
|
In reply to this post by Bob Arning-2
(We're going to have to be careful here not to confuse which Tim you're writing to; if y'all can remember to use a lowercase 't' for me it might help)
On 12-09-2013, at 4:01 PM, Bob Arning <[hidden email]> wrote: > Tim, > > I does not appear to be an image problem. Frank suggested this: > > On 4/26/13 6:17 AM, Frank Shearar wrote >> For those not following the Pharo list, it looks like the root cause >> is that the glibc in Ubuntu 13.04 doesn't immediately write new >> content out to the file. Thus you can "write" to the file, and then >> read from the file, only your RemoteString starts off the end of the >> file. The fix is to make WriteStream >> #nextPutChunk: call "self >> flush". I've pushed a 4.5 fix to trunk, but have not yet done the same >> for the 4.4 and 4.3 update streams. >> >> frank >> >> >> > Some thought this not the nicest solution, but it would be useful to know if the image you are using has had this added or if you can add it and try. > > Frank did add this later after retracting the squeak change > That's correct: patching #nextChunkPut: almost certainly masks the underlying problem, and the more experience Squeakers strongly suggested I revert. I'll post updates as they happen. > If I were experiencing this problem I suspect I'd make the fix and move on rather than re-experience the problem over and over. > > Also see if your Linux distro has fixed it on their end There is, or used to be, code in the FilePlugin that attempted to help with this since a lot of systems had a problem due to over-zealous write caching that ignored self-consistency. Ah, here we are; in sqFilePluingBasicPrims.c, in sqFileWriteFromAt() we have if (f->lastOp == READ_OP) fseek(file, 0, SEEK_CUR); /* seek between reading and writing */ The intent here - and remember this is code over 15 years old - was to force the actual write by inserting a seek. IIRC a flush was considered too expensive. It only really affects unices as far as I can see since RISC OS, OS X & Win32 all have their own more locally customised versions that handle it platform specifically. If unices have changed in such a way that they need more thorough flushing then we need some expert knowledge of the best options. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Science is imagination equipped with grappling hooks. |
|
|
Well, the hack is perfectly understandable. Not
so sure what linux is doing under the covers and that's where thre
problem lies.
Cheers, Bob On 9/12/13 7:20 PM, gettimothy wrote:
|
|
|
In reply to this post by timrowledge
They is very interesting. As it happens, I am studying the Linux Programming Interface a bit each day and File IO is one of the earlier chapters. Perhaps I will learn enough to code a fix. thanks for the pointer to the code. I have it on disk and am doing my first attempt at a VM build now. t. (We're going to have to be careful here not to confuse which Tim you're writing to; if y'all can remember to use a lowercase 't' for me it might help) |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |