ServerDirectory example login is dead
Locked
ServerDirectory example login is dead
 
|
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; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Hypnotized as a child and couldn't be woken. |
Re: ServerDirectory example login is dead
|
|
… 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; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: SLTMDL: Shift Left, Test Mask and Dim the Lights |
Re: ServerDirectory example login is dead
|
|
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" <[hidden email]>: … which leads me to note that ServerDirectory/ |
Re: ServerDirectory example login is dead
|
|
> On 27-12-2017, at 3:36 AM, Jakob Reschke <[hidden email]> 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:[hidden email]//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; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Permanently out to lunch. |
Fwd: ServerDirectory example login is dead
|
|
In reply to this post by timrowledge
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.
tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage |
Re: Fwd: ServerDirectory example login is dead
|
|
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: '[hidden email]'. 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 <[hidden email]> > > 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 <[hidden email]> > > Reply-To: The general-purpose Squeak developers list <[hidden email]> > > > > 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; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: ARG: Agree to Run Garbage > > > |
Re: Fwd: ServerDirectory example login is dead
|
|
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" <[hidden email]> 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: '[hidden email]'. 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 |
Re: Fwd: ServerDirectory example login is dead
|
|
The ideal solution to this must surely be a working demo that connects to our own site?
tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "Bother" said Pooh, as he realised Piglet was undercooked. |
Re: Fwd: ServerDirectory example login is dead
|
|
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 <[hidden email]> wrote: On Mon, Jun 25, 2018 at 11:57:09AM -0700, tim Rowledge wrote: |
Sunday Squeakers (was: Fwd: ServerDirectory example login is dead)
|
|
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 <[hidden email]> 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 <[hidden email]> wrote: On Tue, Jun 26, 2018 at 02:48:56PM -0700, John-Reed Maffeo wrote: |
Re: ServerDirectory example login is dead
|
|
In reply to this post by timrowledge
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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Oxymorons: Clearly misunderstood |
Re: ServerDirectory example login is dead
|
|
How about something like ftp.us.debian.org? Am So., 12. Jan. 2020 um 02:33 Uhr schrieb tim Rowledge <[hidden email]>: 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! |
Re: ServerDirectory example login is dead
|
|
> On 2020-01-18, at 1:55 PM, Jakob Reschke <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim "Both.." said Pooh, as the guillotine came down |
Re: ServerDirectory example login is dead
|
|
On Sat., Jan. 18, 2020, 21:07 tim Rowledge, <[hidden email]> wrote:
frank tim |
Re: ServerDirectory example login is dead
|
|
> On 2020-01-18, at 9:49 PM, Frank Shearar <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Oxymorons: Resident alien |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |