I've been trying to update the NuScratch packages a bit and having 'fun'.
The first problem was simply trying to install the current version; the gpio package has two dependencies and one of them complained that it could not be found. That would be JSON->tonyg.37. Which was a moment's confusion because that is not listed on SM at all, where the versions are 39 a&b. Then I looked at the mcz file in a zip window and noticed that the json tonyg.37 package was included within the mcz, which added some more confusion because it's *right there* so how can it not be found?
After much puzzling I was able to change the dependency to the newer JSON->tony39b and get it uploaded to squeaksource. Anyone wanting a nice monticello project could do worse than improving the tools around those dependencies; we don't see relevant info anywhere except (so far as I could find) in the info window displayed just after saving a package. Nor does it seem we can removed just one dependency out of several.
I then needed to update the SM entry in order to load the updated gpio package. Unfortunately this failed to upload properly - eventually I got a timeout error, which locked up the image for a couple of minutes before finally returning control to me. It looks like the http://map.squeak.org/accountbyid/4340a66e-2296-48b7-9aa8-5305d303752f/files... file didn't get there - attemtping to fetch it results in a 'not here mate' error. Rather confusingly the SM tool does actually show the new version in the list, which isn't reflected in the reality of the web server - opening another image to check in a separate SM catalog shows the lack of the new version. I guess it would be nice to only update the SM tool if the upload is successful.
Two attempts have failed to achieve anything and I don't want to overload the server image if it is having problems. What next?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Try not to let implementation details sneak into design documents.
On 2019-03-14, at 5:07 PM, tim Rowledge tim@rowledge.org wrote:
I've been trying to update the NuScratch packages a bit and having 'fun'.
Tried another couple of times and all I'm seeing is socket timeouts. Is the image blocked?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Sanitary landfill
Hi Tim,
If you click "Edit Release" on "Version382" it shows this: ____ (FileDirectory default directoryExists: 'ScratchSkin') ifFalse:[ UIManager default inform: 'Before loading this package you must download\ http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip%5C and unzip it to create the ScratchSkin directory\ with all the required media files.' withCRs. ^0]. (Installer repository: 'http://www.squeaksource.com/NuScratch' ) install: 'NuScratch-tpr.381.mcz' ____
The first line looks for a file at http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip%5C.
I get a 404 when I tried to access it.
Okay, so then the second line goes after something on squeaksource.com, which is down right now.
I think the problems lie with everything _except_ SqueakMap for the moment.
- Chris
On Thu, Mar 14, 2019 at 7:07 PM tim Rowledge tim@rowledge.org wrote:
I've been trying to update the NuScratch packages a bit and having 'fun'.
The first problem was simply trying to install the current version; the gpio package has two dependencies and one of them complained that it could not be found. That would be JSON->tonyg.37. Which was a moment's confusion because that is not listed on SM at all, where the versions are 39 a&b. Then I looked at the mcz file in a zip window and noticed that the json tonyg.37 package was included within the mcz, which added some more confusion because it's *right there* so how can it not be found?
After much puzzling I was able to change the dependency to the newer JSON->tony39b and get it uploaded to squeaksource. Anyone wanting a nice monticello project could do worse than improving the tools around those dependencies; we don't see relevant info anywhere except (so far as I could find) in the info window displayed just after saving a package. Nor does it seem we can removed just one dependency out of several.
I then needed to update the SM entry in order to load the updated gpio package. Unfortunately this failed to upload properly - eventually I got a timeout error, which locked up the image for a couple of minutes before finally returning control to me. It looks like the http://map.squeak.org/accountbyid/4340a66e-2296-48b7-9aa8-5305d303752f/files... file didn't get there - attemtping to fetch it results in a 'not here mate' error. Rather confusingly the SM tool does actually show the new version in the list, which isn't reflected in the reality of the web server - opening another image to check in a separate SM catalog shows the lack of the new version. I guess it would be nice to only update the SM tool if the upload is successful.
Two attempts have failed to achieve anything and I don't want to overload the server image if it is having problems. What next?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Try not to let implementation details sneak into design documents.
On 2019-03-15, at 1:22 PM, Chris Muller asqueaker@gmail.com wrote:
Hi Tim,
If you click "Edit Release" on "Version382" it shows this: ____ (FileDirectory default directoryExists: 'ScratchSkin') ifFalse:[ UIManager default inform: 'Before loading this package you must download\ http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip%5C and unzip it to create the ScratchSkin directory\ with all the required media files.' withCRs. ^0]. (Installer repository: 'http://www.squeaksource.com/NuScratch' ) install: 'NuScratch-tpr.381.mcz' ____
The first line looks for a file at http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip%5C.
I get a 404 when I tried to access it.
That's odd but probably fixable. At least I hope so, t'would be unpleasant if MIT have withdrawn it in some mena-spirited manner.
Okay, so then the second line goes after something on squeaksource.com, which is down right now.
Urk, well it seemed to be ok something like an hour ago
I think the problems lie with everything _except_ SqueakMap for the moment.
.. except the just mentioned timeouts when trying to saved a release update to it.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim ..... REALITY.SYS Corrupted - Unable to recover Universe
If you click "Edit Release" on "Version382" it shows this: ____ (FileDirectory default directoryExists: 'ScratchSkin') ifFalse:[ UIManager default inform: 'Before loading this package you must download\ http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip%5C and unzip it to create the ScratchSkin directory\ with all the required media files.' withCRs. ^0]. (Installer repository: 'http://www.squeaksource.com/NuScratch' ) install: 'NuScratch-tpr.381.mcz' ____
The first line looks for a file at http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip%5C.
I get a 404 when I tried to access it.
That's odd but probably fixable. At least I hope so, t'would be unpleasant if MIT have withdrawn it in some mena-spirited manner.
Okay, so then the second line goes after something on squeaksource.com, which is down right now.
Urk, well it seemed to be ok something like an hour ago
I think the problems lie with everything _except_ SqueakMap for the moment.
.. except the just mentioned timeouts when trying to saved a release update to it.
We've discussed these before, the most likely scenario is that the serialization on the old 3.x server image is taking a few seconds longer than your timeout setting. Most likely, all is fine.
Click the Update button in a separate image and see if its there.
On 2019-03-15, at 1:31 PM, Chris Muller ma.chris.m@gmail.com wrote:
If you click "Edit Release" on "Version382" it shows this: ____ (FileDirectory default directoryExists: 'ScratchSkin') ifFalse:[ UIManager default inform: 'Before loading this package you must download\ http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip%5C and unzip it to create the ScratchSkin directory\ with all the required media files.' withCRs. ^0]. (Installer repository: 'http://www.squeaksource.com/NuScratch' ) install: 'NuScratch-tpr.381.mcz' ____
The first line looks for a file at http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip%5C.
I get a 404 when I tried to access it.
That's odd but probably fixable. At least I hope so, t'would be unpleasant if MIT have withdrawn it in some mena-spirited manner.
Okay, so then the second line goes after something on squeaksource.com, which is down right now.
Urk, well it seemed to be ok something like an hour ago
I think the problems lie with everything _except_ SqueakMap for the moment.
.. except the just mentioned timeouts when trying to saved a release update to it.
We've discussed these before, the most likely scenario is that the serialization on the old 3.x server image is taking a few seconds longer than your timeout setting. Most likely, all is fine.
Click the Update button in a separate image and see if its there.
Been there, done that, with and without changing the filter to allow 'new safely-available packages'. SM website doesn't show any new release data either.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: PMT: Punch Magnetic Tape
On 2019-03-15, at 1:41 PM, tim Rowledge tim@rowledge.org wrote:
Been there, done that, with and without changing the filter to allow 'new safely-available packages'. SM website doesn't show any new release data either.
And just tried with the timeout set to 90 seconds to no improved effect. It shouldn't be taking long to serialize the 189 characters that were being sent...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Security announcement - as of next week, passwords will be entered in Morse code.
Everything seems to add up to the server having a problem with what you're sending it. If you could construct a clear email with the precise, concise steps (incl. package and version names, etc.) I can follow to reproduce the issue, I might be able to take a look for you.
- Chris
On Fri, Mar 15, 2019 at 5:12 PM tim Rowledge tim@rowledge.org wrote:
On 2019-03-15, at 1:41 PM, tim Rowledge tim@rowledge.org wrote:
Been there, done that, with and without changing the filter to allow 'new safely-available packages'. SM website doesn't show any new release data either.
And just tried with the timeout set to 90 seconds to no improved effect. It shouldn't be taking long to serialize the 189 characters that were being sent...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Security announcement - as of next week, passwords will be entered in Morse code.
I haven't forgotten this and will try to provide stuff to make a good test case.
On 2019-03-16, at 2:45 PM, Chris Muller asqueaker@gmail.com wrote:
Everything seems to add up to the server having a problem with what you're sending it. If you could construct a clear email with the precise, concise steps (incl. package and version names, etc.) I can follow to reproduce the issue, I might be able to take a look for you.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim That’s the second time I’ve seen a Word doc eat a man’s soul. Time for a bug report...
Well, this gets both better and more confusing.
Today I thought I'd spend a few post-lunch minutes trying it out and making a good description for you but a) this time it did actually update the entry on the Squeakmap web page b) it still failed with a timeout during the process; according to the debugger it was trying to POST the 40-50 char description/version string.
After updating SM it was possible to install the package into a clean image, so good news there at least. But timing out on 50 chars seems a bit feeble.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it
I still plan to upgrade the SqueakMap server this year, stay tuned. In the meantime, if you can be gentle and deliberate when updating, it should continue to serve us well enough for the most-important use-case; consumption.
On Sun, Mar 31, 2019 at 5:29 PM tim Rowledge tim@rowledge.org wrote:
Well, this gets both better and more confusing.
Today I thought I'd spend a few post-lunch minutes trying it out and making a good description for you but a) this time it did actually update the entry on the Squeakmap web page b) it still failed with a timeout during the process; according to the debugger it was trying to POST the 40-50 char description/version string.
After updating SM it was possible to install the package into a clean image, so good news there at least. But timing out on 50 chars seems a bit feeble.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it
Argh.
I just tried to update SM for the NuScratch package again. I had saved the new version to SqueakSource and released the version. I opened SM and selected the prior version, chose 'Create New Release'. Updated the install code. Added a commit comment. Set my password. Set the version name. Click on Save'. Wait... timeout!
It failed during the SMReleaseBrowser>savePackageRelease: method, trying to do `smClient save: release`. The actual timeout came as a result of the attempt to read the response, which was reported as 'HTTP/1.1 302 Moved Temporarily
Server: nginx/1.14.2
Date: Sat, 27 Apr 2019 00:31:21 GMT
Content-Type: text/html
Content-Length: 53
Connection: keep-alive
URI: /account
Location: /account
Set-Cookie: SessionID=B2C7C610EB4946C2; path=/
X-Clacks-Overhead: GNU Terry Pratchett
Temporarily moved to: <A HREF="/account">/account</A> {followed by junk}
Seems different to the last problem I had.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Success always occurs in private, and failure in full view.
I'm really sorry Tim. You've stuck with it, it should treat you better. Later this year (est 4th quarter), it will.
It sounds like you went through the correct steps -- the only thing you didn't mention so I'm not sure is whether you're sure ALL four of the lists had a selection. I'm also not sure if you pressed Command+s on all the fields -- but perhaps that doesn't matter anymore since I think you may have fixed that before.
When you hit save, it should come back instantly -- if it timed out it means there was a problem integrating your Install script into the HTTP message request and theres probably a debugger on the server image. I just looked and only saw the old version of NuScratch (10/2018). I was able to Edit Release on that one to see the script. Is all you did was update the .mcz filename, and everything else was the same?
- Chris
On Fri, Apr 26, 2019 at 7:48 PM tim Rowledge tim@rowledge.org wrote:
Argh.
I just tried to update SM for the NuScratch package again. I had saved the new version to SqueakSource and released the version. I opened SM and selected the prior version, chose 'Create New Release'. Updated the install code. Added a commit comment. Set my password. Set the version name. Click on Save'. Wait... timeout!
It failed during the SMReleaseBrowser>savePackageRelease: method, trying to do `smClient save: release`. The actual timeout came as a result of the attempt to read the response, which was reported as 'HTTP/1.1 302 Moved Temporarily
Server: nginx/1.14.2
Date: Sat, 27 Apr 2019 00:31:21 GMT
Content-Type: text/html
Content-Length: 53
Connection: keep-alive
URI: /account
Location: /account
Set-Cookie: SessionID=B2C7C610EB4946C2; path=/
X-Clacks-Overhead: GNU Terry Pratchett
Temporarily moved to: <A HREF="/account">/account</A> {followed by junk}
Seems different to the last problem I had.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Success always occurs in private, and failure in full view.
On 2019-04-26, at 7:01 PM, Chris Muller asqueaker@gmail.com wrote:
I'm really sorry Tim. You've stuck with it, it should treat you better. Later this year (est 4th quarter), it will.
That would be nice, though I've never had this sort of problem in past adventures. Well, not that I can remember right now. See, getting older has some.. wait, what was I talking about?
It sounds like you went through the correct steps -- the only thing you didn't mention so I'm not sure is whether you're sure ALL four of the lists had a selection. I'm also not sure if you pressed Command+s on all the fields -- but perhaps that doesn't matter anymore since I think you may have fixed that before.
Yup, all four lists were set up, I put in password, version name, commit comment and changed a whole single character in the mcz name. I think you may be right about it being me that made the 'save' accept all entries, some faint echo tells me I had at least something to do with it.
When you hit save, it should come back instantly -- if it timed out it means there was a problem integrating your Install script into the HTTP message request and theres probably a debugger on the server image. I just looked and only saw the old version of NuScratch (10/2018). I was able to Edit Release on that one to see the script. Is all you did was update the .mcz filename, and everything else was the same?
It's definitely odd. Is there anything that suggests it might be some weird crap about network setup or routing or whatever? That 301 error thing definitely surprised me but I don't honestly know anything about that part. My expertise pretty much ends at the 418 response code. (https://tools.ietf.org/html/rfc2324#section-2.3.2)
One of the things I think we need to collectively get better at (and I suppose it extends to all software developers!) is handling errors more helpfully. It's hard and tedious in too many cases but worth it eventually. Saving a mcz to SqueakSource for example is *really* annoying when it fails after what seems like a lot of faffing just because you forgot to edit the repository stuff to add the uid/pwd. I bet there's a way to test it immediately and get the user to update before carrying on to success, for example.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Re vera, potas bene = Say, you sure are drinking a lot.
One of the things I think we need to collectively get better at (and I suppose it extends to all software developers!) is handling errors more helpfully.
What is more helpful than the debugger? You really should open it up and take look at the actual HTTP request you sent. Paste it into your email message and we may have a chance to determine what the issue is.
It's hard and tedious in too many cases but worth it eventually. Saving a mcz to SqueakSource for example is *really* annoying when it fails after what seems like a lot of faffing just because you forgot to edit the repository stuff to add the uid/pwd. I bet there's a way to test it immediately and get the user to update before carrying on to success, for example.
No, the way Monticello handles that now is the right way. Interrupting the user unnecessarily is never good, especially when your system is in a half-saved state. First it saves your Version to your package-cache, so you have it no matter what, and your system is in a secure state no matter what. THEN it copies to the remote repository, where things can go wrong (connection, etc.). Adding a modal question saves nothing, since either way, you have the saved Version window on your desktop where you can then copy it once you get your connection sorted.
If we were to improve this area of configuration, let it be to help the user get their mc settings file set up -- because that is the very best solution to that configuration issue. A one time thing, and they never have fiddle with mc id's / pw's in any image again.
- Chris
- Chris
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Re vera, potas bene = Say, you sure are drinking a lot.
Am Sa., 27. Apr. 2019 um 22:29 Uhr schrieb Chris Muller < ma.chris.m@gmail.com>:
One of the things I think we need to collectively get better at (and I
suppose it extends to all software developers!) is handling errors more helpfully.
What is more helpful than the debugger?
I think a debugger popping up is intimidating for beginners and non-programmer users, and it looks like somebody did not properly guard against error cases. Tim and I are neither beginners nor non-programmers, so it is probably even "uncomfortable" for people who just don't know the code that raised the debugger.
It's hard and tedious in too many cases but worth it eventually. Saving
a mcz to SqueakSource for example is *really* annoying when it fails after what seems like a lot of faffing just because you forgot to edit the repository stuff to add the uid/pwd. I bet there's a way to test it immediately and get the user to update before carrying on to success, for example.
No, the way Monticello handles that now is the right way. [...] First it saves your Version to your package-cache, [...] you have the saved Version window on your desktop where you can then copy it once you get your connection sorted.
New users don't know about this fail-safe mechanism, and probably neither that they can retry the upload with the copy button. Years ago I would have believed that the save failed altogether and I got a worthless, leftover (probably defunct) window for the version anyway. Of course, this perception is wrong, but what tells one otherwise? Some kind of diagnostic and instruction text could do that. One could display it instead of or in addition to a debugger.
We have this notifier window with the proceed, abort, debug buttons. One solution might be to fill it with more helpful text in such situations, instead of the stack trace. Like it is done for Warnings.
"Your version was saved to the disk, but it could not be uploaded to the server. You can retry the upload by using the Copy button on the Version inspector that was opened for you [could add a Text action here to make that SystemWindow flash]. Press "Proceed" to [...]. Press "Abort" to [...]. Press "Debug" to look into the issue. Useful information to mention if you want to ask for help: [exception message or a context-specific excerpt of variables]"
Sometimes I wish for a "Retry" button there and a restart mechanism like the one in Common Lisp. http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-res...
If we were to improve this area of configuration, let it be to help the user get their mc settings file set up -- because that is the very best solution to that configuration issue. A one time thing, and they never have fiddle with mc id's / pw's in any image again.
Maybe, I didn't know about this settings file until you mentioned it a few weeks ago. Is there anything that tells one how to use it at the moment? Note that it does not resolve the situation when there is a connection problem not related to configuration, such as an outage.
I like your analysis Jakob! I agree with everything you said.
What if the Pre-Debug window were re-arranged to look like a more-conventional error message? One super easy thing would be to put the [Proceed] [Abandon] [Debug] buttons at the bottom, where they're normally expected. And, yes, only the error message would show in the middle instead of the stack. This may help with the intimidation factor you mentioned for users.
I have long held that Squeak should embrace #noviceMode, so we can customize cases like this to make Squeak what a user wants, or what developer wants, at the flip of a switch.
Best, Chris
One of the things I think we need to collectively get better at (and I suppose it extends to all software developers!) is handling errors more helpfully.
What is more helpful than the debugger?
I think a debugger popping up is intimidating for beginners and non-programmer users, and it looks like somebody did not properly guard against error cases. Tim and I are neither beginners nor non-programmers, so it is probably even "uncomfortable" for people who just don't know the code that raised the debugger.
It's hard and tedious in too many cases but worth it eventually. Saving a mcz to SqueakSource for example is *really* annoying when it fails after what seems like a lot of faffing just because you forgot to edit the repository stuff to add the uid/pwd. I bet there's a way to test it immediately and get the user to update before carrying on to success, for example.
No, the way Monticello handles that now is the right way. [...] First it saves your Version to your package-cache, [...] you have the saved Version window on your desktop where you can then copy it once you get your connection sorted.
New users don't know about this fail-safe mechanism, and probably neither that they can retry the upload with the copy button. Years ago I would have believed that the save failed altogether and I got a worthless, leftover (probably defunct) window for the version anyway. Of course, this perception is wrong, but what tells one otherwise? Some kind of diagnostic and instruction text could do that. One could display it instead of or in addition to a debugger.
We have this notifier window with the proceed, abort, debug buttons. One solution might be to fill it with more helpful text in such situations, instead of the stack trace. Like it is done for Warnings.
"Your version was saved to the disk, but it could not be uploaded to the server. You can retry the upload by using the Copy button on the Version inspector that was opened for you [could add a Text action here to make that SystemWindow flash]. Press "Proceed" to [...]. Press "Abort" to [...]. Press "Debug" to look into the issue. Useful information to mention if you want to ask for help: [exception message or a context-specific excerpt of variables]"
Sometimes I wish for a "Retry" button there and a restart mechanism like the one in Common Lisp. http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-res...
If we were to improve this area of configuration, let it be to help the user get their mc settings file set up -- because that is the very best solution to that configuration issue. A one time thing, and they never have fiddle with mc id's / pw's in any image again.
Maybe, I didn't know about this settings file until you mentioned it a few weeks ago. Is there anything that tells one how to use it at the moment? Note that it does not resolve the situation when there is a connection problem not related to configuration, such as an outage.
If we were to improve this area of configuration, let it be to help the user get their mc settings file set up -- because that is the very best solution to that configuration issue. A one time thing, and they never have fiddle with mc id's / pw's in any image again.
Maybe, I didn't know about this settings file until you mentioned it a few weeks ago. Is there anything that tells one how to use it at the moment?
No, that's why I was suggesting we try to think of an elegant way to help users get this set up. Like maybe Marcel's opening welcome wizard? Add a new "Settings" button to the Monticello browser?
Note that it does not resolve the situation when there is a connection problem not related to configuration, such as an outage.
squeak-dev@lists.squeakfoundation.org