If one tries to add a remote directory to a FileList the example server details lists the no longer extant st.cs.uiuc.edu, which is a little disappointing.
Do we have a good replacement? Preferably a good place on our own server(s)? I did actually try files.squeak.org but that a) failed b) exposed me to the great joy of a loop of unhandled error handling handling errors in erroneous handling.
I *can* get to my own server, so the basics still function - but I’m not providing access to that for the world in general.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Hypnotized as a child and couldn't be woken.
… which leads me to note that ServerDirectory/RemoteFileStream seem to need some love, and it would be nice to integrate them better wrt file name stuff.
See ServerDirectory class>>#defaultStemUrl, for example - I’m fairly sure disney wouldn’t want us trying to save Books on ‘jumbo’ any more.
Consider that whilst FileList tries to handle remote directories, it fails horribly if you try to look at, say, a gif file on a remote server because the code asks for the full name of the file (rowledge.org//tag-comment.gif for example) and passes that to Form fromFileNamed: Since our filename handling stinks, it doesn’t work out that it needs to make a remote file stream etc. It really is way past time we had a decent file name handling system that can sensibly deal with stuff like that, and the need to (often) convert file name related strings to/from UTF-8 when talking to a VM, and so on and so forth.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SLTMDL: Shift Left, Test Mask and Dim the Lights
I have not thoroughly investigated this, but this could be a case for the FileSystem API that Pharo has adopted as the default file accessing API. You do not pass file names around there, but references that are (path + the FileSystem in which they resolve). That way, the information that the gif lives remotely is not lost. Each FileSystem is then responsible for file name conversion and encoding if required.
Am 26.12.2017 22:15 schrieb "tim Rowledge" tim@rowledge.org:
… which leads me to note that ServerDirectory/RemoteFileStream seem to need some love, and it would be nice to integrate them better wrt file name stuff.
See ServerDirectory class>>#defaultStemUrl, for example - I’m fairly sure disney wouldn’t want us trying to save Books on ‘jumbo’ any more.
Consider that whilst FileList tries to handle remote directories, it fails horribly if you try to look at, say, a gif file on a remote server because the code asks for the full name of the file (rowledge.org//tag-comment.gif for example) and passes that to Form fromFileNamed: Since our filename handling stinks, it doesn’t work out that it needs to make a remote file stream etc. It really is way past time we had a decent file name handling system that can sensibly deal with stuff like that, and the need to (often) convert file name related strings to/from UTF-8 when talking to a VM, and so on and so forth.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SLTMDL: Shift Left, Test Mask and Dim the Lights
On 27-12-2017, at 3:36 AM, Jakob Reschke forums.jakob@resfarm.de wrote:
I have not thoroughly investigated this, but this could be a case for the FileSystem API that Pharo has adopted as the default file accessing API. You do not pass file names around there, but references that are (path + the FileSystem in which they resolve). That way, the information that the gif lives remotely is not lost. Each FileSystem is then responsible for file name conversion and encoding if required.
That’s certainly one option and potentially a very good one. I’ve always hated the way that raw strings have ended up as the ‘normal’ way to refer to file locations. It got even worse with UTF-8 getting mixed in. There’s a lot to be said for having fairly use-specific objects to refer to file locations; it might be smart to have platform specific classes not just for the differing separators, length limits and so on, but as a way to help translating between OS as an image is moved around. As a current example, the Turing talk image Yoshiki just mentioned has a link to a movie file at C:\something or other; a way to meaningfully convert that would be very nice for Mac & linux (and RISC OS!) users. Another option is to have an abstracted form that works from one or more known locations - the default directory is one obvious starting point - and doesn’t particularly use any OS idea of format but can be converted easily. How about "(FileSystem defaultDir up up up dir: ‘wibble’ dir:’splot’) fileNames” instead of “(FileDirectory default directoryNamed: ‘../../../wibble/splot’) fileNames ?
An interesting option we have these days because of the common requirement for UTF-8 filenames etc is that, since we have to convert the string anyway, building a single platform format string from a collection of path components no longer seems like an insane amount of work to do for a ‘mere file name call’.
One of our problems is that people have got so used to thinking of filenames as just strings that they can append to or trim. It will be hard to get us to use anything else, no matter how much better it can be demonstrated to be.
Another problem is illustrated quite well by the horrible ways we have to guard so many methods in FileDirectory against nasty file paths being thrown around. Consider FileDirectory default directoryNamed: '/home’ -> UnixFileDirectory on '/home’ In order to support that we have to check the given local file name for all sorts of cruft. This may well be repeated half a dozen times in a single interaction with a file and if a hard-coded OS inappropriate string is used we can really get messed up. Proper private methods and actual APIs might help a bit here.
A different option that I suppose might seem more familiar to a lot of people would be to adopt the URI style and end up with things like ftp:blob:wiblley2@thingummy.org//a/b/c.gif (or whatever the syntax actually is)
Whichever path we take I really hope we can build a better selection of name handling capabilities; working on the FileChooserDialog etc has really been quite annoying; oh, we can get the extension of a file name... and the local name, and the basename, but wait that includes the path…
On the plus side, I did manage to get the basics of remote directories working within the FileChooserDialog yesterday but I’m loathe to include it since the operations seem so terribly slow. Part of it is a side-effect of our LazyList morphs compounded by slow ftp responses. Another part is the problem of a remote file name not getting parsed if we try to do FileDirectory fileNamed: ‘rowledge.org//tag-comment.gif'
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Permanently out to lunch.
I asked about this last year; with a release looming it would be nice to have a working server to point to instead of a non-existent one.
Begin forwarded message:
From: tim Rowledge tim@rowledge.org Subject: [squeak-dev] ServerDirectory example login is dead Date: December 26, 2017 at 10:59:56 AM PST To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Reply-To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
If one tries to add a remote directory to a FileList the example server details lists the no longer extant st.cs.uiuc.edu, which is a little disappointing.
Do we have a good replacement? Preferably a good place on our own server(s)? I did actually try files.squeak.org but that a) failed b) exposed me to the great joy of a loop of unhandled error handling handling errors in erroneous handling.
I *can* get to my own server, so the basics still function - but I’m not providing access to that for the world in general.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage
After googling for "public anonymous ftp servers", I tried this in the workspace that pops up from the add server... menu selection in a file list:
| aa | self flag: #ViolateNonReferenceToOtherClasses. aa := ServerDirectory new. aa server: 'speedtest.tele2.net'. "host" aa user: 'anonymous'. aa password: 'yourEmail@school.edu'. aa directory: '/'. aa url: ''. "<- this is optional. Only used when *writing* update files." ServerDirectory addServer: aa named: 'Tele2 speed test'. "<- known by this name in Squeak"
It works, but it quickly exposes problems in the RemoteServer, so I'm not sure that fixing the FileList example server before the 5.2 release would be a good thing to do. Maybe better to leave it pointing to the old st.cs.uiuc.edu for now, at least that way people will not be expecting too much from it.
Nowadays, I think people would be more likely to use http for file serving rather that ftp. But have a look at HTTPServerDirectory, and you can see that some cleanups are in order. It looks like somebody intended to do this back in 2001 and did not get too far with it. This would be a good project for someone to take on in the coming months: refactor the ServerDirectory hierarchy, keeping the SuperSwikiServer part functional, and making HTTPServerDirectoy into somthing real.
For the record, bugs that I quickly noticed when adding the speedtest.tele2.net server to to a FileList:
- The file list does not get updated to show the new server. Open a new file list and the server will be there, but it will not appear in the original file list from which it was created.
- Likewise, when the server is removed, the file list is not updated.
- Files in in remote directory can be selected, but many of the selections result in a protocol error. For example, selecting the 500MB.zip file in the FileList results in a TelnetProtocolError.
- If I select the 1KB.zip file, and click the 'open zip' button, I get a FileDoesNotExistException.
Dave
On Tue, Jun 19, 2018 at 08:20:35AM -0700, tim Rowledge wrote:
I asked about this last year; with a release looming it would be nice to have a working server to point to instead of a non-existent one.
Begin forwarded message:
From: tim Rowledge tim@rowledge.org Subject: [squeak-dev] ServerDirectory example login is dead Date: December 26, 2017 at 10:59:56 AM PST To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Reply-To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
If one tries to add a remote directory to a FileList the example server details lists the no longer extant st.cs.uiuc.edu, which is a little disappointing.
Do we have a good replacement? Preferably a good place on our own server(s)? I did actually try files.squeak.org but that a) failed b) exposed me to the great joy of a loop of unhandled error handling handling errors in erroneous handling.
I *can* get to my own server, so the basics still function - but I???m not providing access to that for the world in general.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage
About this, I share my experiments. On my squeakros.org site if I select the right user and pass I use in Cyberduck , get tons of complains.
If I use a old trick like:
In a older .image which works well with servers do
ServerDirectory servers inspect.
In the code panel do self saveOnFile , "use servers.obj as name"
In 5.2 or any Squeak:
| inputStream anObject | inputStream _ FileStream oldFileNamed: 'servers.obj'. anObject _ inputStream fileInObjectAndCode. inputStream close. (Inspector openAsMorphOn: anObject) openInHand
ServerDirectory serversFrom: self!
This works with same problems Dave report
Edgar @morplenauta
On 24/06/2018, 11:59, "David T. Lewis" lewis@mail.msen.com wrote:
After googling for "public anonymous ftp servers", I tried this in the workspace
that pops up from the add server... menu selection in a file
list:
| aa | self flag: #ViolateNonReferenceToOtherClasses. aa :=
ServerDirectory new.
aa server: 'speedtest.tele2.net'. "host" aa user:
'anonymous'.
aa password: 'yourEmail@school.edu'. aa directory: '/'. aa
url: ''. "<- this is optional. Only used when *writing* update files."
ServerDirectory addServer: aa named: 'Tele2 speed test'. "<- known
by this name in Squeak"
It works, but it quickly exposes problems in the
RemoteServer, so I'm
not sure that fixing the FileList example server before
the 5.2 release
would be a good thing to do. Maybe better to leave it pointing
to the old
st.cs.uiuc.edu for now, at least that way people will not be
expecting
too much from it.
Nowadays, I think people would be more likely to
use http for file serving
rather that ftp. But have a look at
HTTPServerDirectory, and you can see
that some cleanups are in order. It looks
like somebody intended to do this
back in 2001 and did not get too far with
it. This would be a good project
for someone to take on in the coming months:
refactor the ServerDirectory
hierarchy, keeping the SuperSwikiServer part
functional, and making
HTTPServerDirectoy into somthing real.
For the record,
bugs that I quickly noticed when adding the speedtest.tele2.net
server to to a
FileList:
- The file list does not get updated to show the new server. Open a
new
file list and the server will be there, but it will not appear in
the
original file list from which it was created.
- Likewise, when the server
is removed, the file list is not updated.
- Files in in remote directory can
be selected, but many of the selections
result in a protocol error. For
example, selecting the 500MB.zip file in
the FileList results in a
TelnetProtocolError.
- If I select the 1KB.zip file, and click the 'open zip'
button, I
get a FileDoesNotExistException.
Dave
The ideal solution to this must surely be a working demo that connects to our own site?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as he realised Piglet was undercooked.
On Mon, Jun 25, 2018 at 11:57:09AM -0700, tim Rowledge wrote:
The ideal solution to this must surely be a working demo that connects to our own site?
Yes for sure, files.squeak.org seems like the obvious thing to use as an example. I also think that an ideal solution is going to require a bit of work on somebody's part, because that ServerDirectory hierarchy needs some love. Commits to the inbox would be welcome, but maybe hold off until after the 5.2 release to move changes to trunk.
This would be a great "Sunday Squeaker" project. Any takers?
Dave
Hmmm... Did I miss the memo? Is "Sunday Squeaker" a new role in the "Great Chain of Squeakers"? something between noob and Knight of the Square Bracket?
Let me know and I will update the WackyWiki ;-)
-jrm
On Mon, Jun 25, 2018 at 4:13 PM David T. Lewis lewis@mail.msen.com wrote:
On Mon, Jun 25, 2018 at 11:57:09AM -0700, tim Rowledge wrote:
The ideal solution to this must surely be a working demo that connects
to our own site?
Yes for sure, files.squeak.org seems like the obvious thing to use as an example. I also think that an ideal solution is going to require a bit of work on somebody's part, because that ServerDirectory hierarchy needs some love. Commits to the inbox would be welcome, but maybe hold off until after the 5.2 release to move changes to trunk.
This would be a great "Sunday Squeaker" project. Any takers?
Dave
On Tue, Jun 26, 2018 at 02:48:56PM -0700, John-Reed Maffeo wrote:
Hmmm... Did I miss the memo? Is "Sunday Squeaker" a new role in the "Great Chain of Squeakers"? something between noob and Knight of the Square Bracket?
Let me know and I will update the WackyWiki ;-)
I think it is a very old role. A Sunday Squeaker is someone who enjoys working or playing with Squeak with a nice fresh pot of good coffee at hand on a relaxing Sunday morning or afternoon.
I have always thought of myself as a Sunday Squeaker, but I guess I'm not sure if anyone ever put out the memo. After all, that would require more initiative than someone like me would ever be likely to muster on a Sunday.
Just in case it turns out to be me who accidentally introduced the term "Sunday Squeaker", I want to note for the historical record that I would have been inspired by the late great Ken Willard who for many years wrote my favorite column in the "Model Airplane News" or "Radio Control Modeler" magazine (one of those, I don't quite remember which). Ken was a committed amateur enthusiast, and he inspired me when I was a kid and probably still subliminally inspires me today.
Reference: https://www.modelaircraft.org/files/WillardKen.pdf
Dave
-jrm
On Mon, Jun 25, 2018 at 4:13 PM David T. Lewis lewis@mail.msen.com wrote:
On Mon, Jun 25, 2018 at 11:57:09AM -0700, tim Rowledge wrote:
The ideal solution to this must surely be a working demo that connects
to our own site?
Yes for sure, files.squeak.org seems like the obvious thing to use as an example. I also think that an ideal solution is going to require a bit of work on somebody's part, because that ServerDirectory hierarchy needs some love. Commits to the inbox would be welcome, but maybe hold off until after the 5.2 release to move changes to trunk.
This would be a great "Sunday Squeaker" project. Any takers?
Dave
Well I guess that is me too, except these days, my effort is not limited to Sundays ;-)
- jrm
On Tue, Jun 26, 2018 at 6:30 PM David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 26, 2018 at 02:48:56PM -0700, John-Reed Maffeo wrote:
Hmmm... Did I miss the memo? Is "Sunday Squeaker" a new role in the
"Great
Chain of Squeakers"? something between noob and Knight of the Square Bracket?
Let me know and I will update the WackyWiki ;-)
I think it is a very old role. A Sunday Squeaker is someone who enjoys working or playing with Squeak with a nice fresh pot of good coffee at hand on a relaxing Sunday morning or afternoon.
I have always thought of myself as a Sunday Squeaker, but I guess I'm not sure if anyone ever put out the memo. After all, that would require more initiative than someone like me would ever be likely to muster on a Sunday.
Just in case it turns out to be me who accidentally introduced the term "Sunday Squeaker", I want to note for the historical record that I would have been inspired by the late great Ken Willard who for many years wrote my favorite column in the "Model Airplane News" or "Radio Control Modeler" magazine (one of those, I don't quite remember which). Ken was a committed amateur enthusiast, and he inspired me when I was a kid and probably still subliminally inspires me today.
Reference: https://www.modelaircraft.org/files/WillardKen.pdf
Dave
-jrm
On Mon, Jun 25, 2018 at 4:13 PM David T. Lewis lewis@mail.msen.com
wrote:
On Mon, Jun 25, 2018 at 11:57:09AM -0700, tim Rowledge wrote:
The ideal solution to this must surely be a working demo that
connects
to our own site?
Yes for sure, files.squeak.org seems like the obvious thing to use as an example. I also think that an ideal solution is going to require a bit of work on somebody's part, because that ServerDirectory hierarchy needs some love. Commits to the inbox would be welcome, but maybe hold off until after the 5.2 release to move changes to trunk.
This would be a great "Sunday Squeaker" project. Any takers?
Dave
A couple of years ago as we prepared a release I asked about this and as best I know we didn't get anything settled. Sure, it's hardly a major issue but I do like to se examples actually do what they a re supposed to be examples for!
On 2017-12-26, at 10:59 AM, tim Rowledge tim@rowledge.org wrote:
If one tries to add a remote directory to a FileList the example server details lists the no longer extant st.cs.uiuc.edu, which is a little disappointing.
Do we have a good replacement? Preferably a good place on our own server(s)? I did actually try files.squeak.org but that a) failed b) exposed me to the great joy of a loop of unhandled error handling handling errors in erroneous handling.
I *can* get to my own server, so the basics still function - but I’m not providing access to that for the world in general.
So, the obvious first question is whether anyone knows a suitable ftp site we can point to in this example? A possibly more interesting question is whether anyone has ever updated the FTPClient code to handle sftp; I'm taking a look around but can't see anything that stands out to me. If so, then the range of possible sites for the example is considerably wider. If not, well, now is not the time to add it but it sure would be nice to have all our internet stuff bang up to date and fully buzzword compliant.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Clearly misunderstood
How about something like ftp.us.debian.org?
Am So., 12. Jan. 2020 um 02:33 Uhr schrieb tim Rowledge tim@rowledge.org:
A couple of years ago as we prepared a release I asked about this and as best I know we didn't get anything settled. Sure, it's hardly a major issue but I do like to se examples actually do what they a re supposed to be examples for!
On 2017-12-26, at 10:59 AM, tim Rowledge tim@rowledge.org wrote:
If one tries to add a remote directory to a FileList the example server
details lists the no longer extant st.cs.uiuc.edu, which is a little disappointing.
Do we have a good replacement? Preferably a good place on our own
server(s)? I did actually try files.squeak.org but that
a) failed b) exposed me to the great joy of a loop of unhandled error handling
handling errors in erroneous handling.
I *can* get to my own server, so the basics still function - but I’m not
providing access to that for the world in general.
So, the obvious first question is whether anyone knows a suitable ftp site we can point to in this example? A possibly more interesting question is whether anyone has ever updated the FTPClient code to handle sftp; I'm taking a look around but can't see anything that stands out to me. If so, then the range of possible sites for the example is considerably wider. If not, well, now is not the time to add it but it sure would be nice to have all our internet stuff bang up to date and fully buzzword compliant.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Clearly misunderstood
On 2020-01-18, at 1:55 PM, Jakob Reschke forums.jakob@resfarm.de wrote:
ftp.us.debian.org
That weirdly fails. As in, I can open a browser on it. I can try to open an ftp client on it with `FTPClient openOnHostNamed: 'ftp.us.debian.org'` and it worked one time but still failed to work in the FileBrowser, but never again. It simply fails to resolve the name to an IP. The one time it did resolve the response message was rather sternly telling people not to use it!
To make it more fun we get a not terribly amusing un-endable cycle of a notifier telling me that 'Could not resolve the server named:' etc, which is the default action of a NameLookupFailure signal. If you 'give up' you then go on to another error (somebody should be catching that 'give up' state) and when using the FileBrowser that results in another cycle because the ServerDirectory>>#wakeUp method gets run again and again and again, each time finding in ServerDirectory>>#openFTPClient that 'client' is nil and so trying to open the connection and... weren't we just here?
So again with two errors
a) for some reason the host name won't resolve (usually)
b) some better error handling is needed between the file browser, ServerDirectory and FTPClient. There has to be some balance between trying and retrying to connect and deciding it isn't going to work and forgetting about it. I'm not sure where that balance should lie in order to be both helpful and not infuriating. Certainly it's more than a bit irritating right now.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Both.." said Pooh, as the guillotine came down
On Sat., Jan. 18, 2020, 21:07 tim Rowledge, tim@rowledge.org wrote:
On 2020-01-18, at 1:55 PM, Jakob Reschke forums.jakob@resfarm.de
wrote:
ftp.us.debian.org
That weirdly fails. As in, I can open a browser on it. I can try to open an ftp client on it with `FTPClient openOnHostNamed: 'ftp.us.debian.org'` and it worked one time but still failed to work in the FileBrowser, but never again. It simply fails to resolve the name to an IP. The one time it did resolve the response message was rather sternly telling people not to use it!
To make it more fun we get a not terribly amusing un-endable cycle of a notifier telling me that 'Could not resolve the server named:' etc, which is the default action of a NameLookupFailure signal. If you 'give up' you then go on to another error (somebody should be catching that 'give up' state) and when using the FileBrowser that results in another cycle because the ServerDirectory>>#wakeUp method gets run again and again and again, each time finding in ServerDirectory>>#openFTPClient that 'client' is nil and so trying to open the connection and... weren't we just here?
So again with two errors
a) for some reason the host name won't resolve (usually)
b) some better error handling is needed between the file browser, ServerDirectory and FTPClient. There has to be some balance between trying and retrying to connect and deciding it isn't going to work and forgetting about it. I'm not sure where that balance should lie in order to be both helpful and not infuriating. Certainly it's more than a bit irritating right now.
https://tech.labs.oliverwyman.com/blog/2011/01/04/try-again-with-exceptions/ might help.
frank
tim
-- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Both.." said Pooh, as the guillotine came down
On 2020-01-18, at 9:49 PM, Frank Shearar frank.shearar@gmail.com wrote:
https://tech.labs.oliverwyman.com/blog/2011/01/04/try-again-with-exceptions/ might help.
It's a decent explanation of the sort of problem we're seeing.
Basically I think the lookup fails and 'giving up' doesn't actually result in giving up because some better error checking needs to be done. And on top of that the file browser assumes that it's a good idea to repeatedly ask a directory to wakeUp, and the ServerDirectory wakeUp method thinks that client isNil is a proper way to decide that we need to open the ftp client and nowhere does any code handle the possibility that the ftp connection is dead, deceased, an ex-connection that has shuffled off to join the finalisation queue invisible.
I think it needs to be possible to flag the ServerDirectory as somnolent in some fashion. After trying to connect and failing (for whatever reason) the sleepy ftp client should probably be kept around so that the file list can deliberately retry the connection if the user asks, or delete it from the list of servers etc.
It's certainly more changes than we should consider at this stage of a hopeful release cycle.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Resident alien
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Edgar J. De Cleene -
Frank Shearar -
Jakob Reschke -
John-Reed Maffeo -
tim Rowledge