Opened 9 years ago

Closed 7 years ago

#11026 closed enhancement (fixed)

Add double clicking of sws files for Mac app

Reported by: iandrus Owned by: iandrus
Priority: major Milestone: sage-5.8
Component: user interface Keywords: mac app
Cc: kcrisman, jhpalmieri Merged in: sage-5.8.beta0
Authors: Ivan Andrus Reviewers: Karl-Dieter Crisman, Nicholas Kirchner, John Palmieri
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by iandrus)

With #8473 we have the necessary support for uploading files. This allows the Mac app to support double clicking of sws files. Also able to be opened are txt and zip files.


Apply trac_11026-extcode.patch, trac_11026-fix-parse-error.patch and trac_11026-warnings.patch to the extcode repository. Also apply trac_11026-plist-strings.patch to the scripts repository.

Attachments (6)

trac_11026-extcode-rebase.patch (173.0 KB) - added by kcrisman 7 years ago.
Based on 5.1beta1
trac_11026-extcode-rebase.2.patch (173.0 KB) - added by kcrisman 7 years ago.
Based on 5.1.beta1
trac_11026-extcode.patch (301.8 KB) - added by iandrus 7 years ago.
trac_11026-fix-parse-error.patch (1.1 KB) - added by iandrus 7 years ago.
trac_11026-warnings.patch (3.0 KB) - added by iandrus 7 years ago.
trac_11026-plist-strings.patch (741 bytes) - added by iandrus 7 years ago.

Download all attachments as: .zip

Change History (84)

comment:1 Changed 9 years ago by kcrisman

  • Cc kcrisman added

comment:2 Changed 9 years ago by kcrisman

I think the patch already exists, right? You could just add it and mark 'needs review'.

comment:3 Changed 9 years ago by iandrus

  • Owner changed from was to iandrus

comment:4 Changed 9 years ago by iandrus

  • Status changed from new to needs_review

comment:5 Changed 8 years ago by kcrisman

This would eventually need also to add html (#10652) and other file types as possible uploads, but I think that those could be additional enhancements to the Mac app.

I have to admit that some of the stuff in designable.nib I will never understand. I see the "new option to automatically start the server when a sws file is opened" from #8473, but some of the things like "IBConnectionRecord" and the mysterious numbers everywhere I can only judge by their effects. I am impressed by all the work bringing the double-click not just to the browser but to the mini-browser you built.

I'll be testing this shortly.

comment:6 Changed 8 years ago by kcrisman

I get a weird error, perhaps related to the problems with browsers at #8473, with this:

The resource /upload_worksheet?url=file://localhost/Users/student/Desktop/Tests.sws cannot be found.

Notice the file://localhost/Users rather than file:///Users which we get at #8473.

comment:7 Changed 8 years ago by kcrisman

From #8473:

The Mac app has a new option to automatically start the server when a sws file is opened. I'm not sure anyone would ever want to turn this off, so I can remove it if it's not useful.

But it does work as advertised. I can imagine one wanting to avoid 'accidentally' starting the server, so let's keep it.

The rest seems to work as it's supposed to, modulo the issues mentioned at #8473.

comment:8 Changed 8 years ago by kcrisman

  • Reviewers set to Karl-Dieter Crisman

Here's a couple more interesting details.

  • Changing the default browser to FF, it still worked! Even if the server was started.
  • BUT if the app was completely turned off, then I got the message about the following not being found - no surprise, as port 0 probably is not open!
    http://localhost:0/upload_worksheet?url=file://localhost/Users/karl-dietercrisman/Desktop/Test.sws
    
    That is certainly some kind of residue from #8473, with somehow the initial port 0 not being changed soon enough or something. You could follow up there if it makes more sense.

comment:9 Changed 8 years ago by kcrisman

Separately, I just experienced the phenomenon of closing the app turning off a different Sage server session! At least that's what it seemed like.

comment:10 Changed 8 years ago by kcrisman

I also get a strange 'doubling' of the pages just now - not before. I'm not sure what's causing it, but somehow it's opening two copies of the loading page, etc. I'm getting port 8001 right now, so maybe that's it.

Now it seems to be more normal again, though I still got two copies of the worksheet, presumably from your !URLQueue. Anyway, not something I'm really concerned with, since it's working nonetheless.

comment:11 Changed 8 years ago by kcrisman

  • Status changed from needs_review to needs_work

Putting to 'needs work'.

  • At least it should work with #8473.
  • The port 0 thing should probably work.
  • The other stuff isn't as important. Probably needs a little more testing in any case, but the concept is more than proven.

comment:12 Changed 7 years ago by kcrisman

  • Status changed from needs_work to needs_info

#8473 is solved, see the sagenb upstream pull request.

Putting this to "needs info" because I don't know whether this patch will be compatible with the new notebook.

Changed 7 years ago by kcrisman

Based on 5.1beta1

comment:13 Changed 7 years ago by kcrisman

  • Dependencies set to #8473, #13121
  • Description modified (diff)
  • Status changed from needs_info to needs_review

I just rebased this, because of a slight change when sage-env was moved. Shouldn't have any other new notebook problems, see comment:12:ticket:10556. Now it's time to look at it!

Dependencies include #13121, where #8473 will eventually live.

Apply trac_11026-extcode-rebase.patch to the extcode repository.

comment:14 Changed 7 years ago by kcrisman

By the way, for positive review I think it's reasonable to ask for this to be tested on Tiger, Snow Leopard, and Lion, with up-to-date Xcode for each platform.

comment:15 follow-up: Changed 7 years ago by kcrisman

  • Status changed from needs_review to needs_work

Well, it's a little tricky. Double-clicking certainly opens the Sage app, and the notebook server opens, but I don't see it opening the file. Yes, this is on a version of Sage with the sws-cmdline going, because if I open the terminal from within the little dropdown list, I get

sage: notebook(upload="/Users/.../Untitled.sws")
The notebook files are stored in: sage_notebook.sagenb
Another Sage Notebook server is running, PID 19872.
Opening web browser at http://localhost:8000/upload_worksheet?url=file:///Users/.../Untitled.sws ...

and it opens fine in its own thing. But when I double-click, it just opens the worksheet list window, nothing else.

When I use the Sage app itself (not the little menubar item) and do File -> Open File ... then I get the "native" app browser with the worksheet I chose as its title, but nothing else (just a clank browser window. It doesn't do anything, and the worksheet is not there when I check.

The only possible problem is that I built this as an Xcode project and then dumped in my Sage that has the sws-cmdline business. But it functions fine otherwise, so I don't know what the story is with this. Sadly, 'needs work'.

Also, I have a feeling that it doesn't wait long enough to upload in any case, but that would be a separate issue.


On an unrelated note, why does sage-document-cython.icns look so much bigger than the other icon files?


By the way, my menubar item never does become blue any more. Maybe that is part of it. I mean, the server is clearly working, so I'm not sure why not. Any ideas?

comment:16 in reply to: ↑ 15 ; follow-up: Changed 7 years ago by iandrus

Replying to kcrisman:

Well, it's a little tricky. Double-clicking certainly opens the Sage app, and the notebook server opens, but I don't see it opening the file. Yes, this is on a version of Sage with the sws-cmdline going, because if I open the terminal from within the little dropdown list, I get

sage: notebook(upload="/Users/.../Untitled.sws")
The notebook files are stored in: sage_notebook.sagenb
Another Sage Notebook server is running, PID 19872.
Opening web browser at http://localhost:8000/upload_worksheet?url=file:///Users/.../Untitled.sws ...

and it opens fine in its own thing. But when I double-click, it just opens the worksheet list window, nothing else.

When I use the Sage app itself (not the little menubar item) and do File -> Open File ... then I get the "native" app browser with the worksheet I chose as its title, but nothing else (just a clank browser window. It doesn't do anything, and the worksheet is not there when I check.

Oh you're right. I wonder if that ever worked.


On an unrelated note, why does sage-document-cython.icns look so much bigger than the other icon files?

I made it at a different time and didn't follow the same steps I guess. I fixed this in the patch as well.


By the way, my menubar item never does become blue any more. Maybe that is part of it. I mean, the server is clearly working, so I'm not sure why not. Any ideas?

Okay, I tried it against sage-5.2.beta0 and you are right (when you use the system browser). The problem is the server detection. They changed the (default) pid file of the notebook server. I have fixed this and tested that it also works with the old pid file, and updated the patch.

comment:17 Changed 7 years ago by iandrus

  • Description modified (diff)

comment:18 Changed 7 years ago by iandrus

  • Status changed from needs_work to needs_review

comment:19 Changed 7 years ago by kcrisman

Notice that you still have the failing hunk.

Changed 7 years ago by kcrisman

Based on 5.1.beta1

comment:20 Changed 7 years ago by kcrisman

  • Description modified (diff)

comment:21 in reply to: ↑ 16 ; follow-up: Changed 7 years ago by kcrisman

Well, it's a little tricky. Double-clicking certainly opens the Sage app, and the notebook server opens, but I don't see it opening the file. Yes, this is on a version of Sage with the sws-cmdline going, because if I open the terminal from within the little dropdown list, I get

sage: notebook(upload="/Users/.../Untitled.sws")
The notebook files are stored in: sage_notebook.sagenb
Another Sage Notebook server is running, PID 19872.
Opening web browser at http://localhost:8000/upload_worksheet?url=file:///Users/.../Untitled.sws ...

and it opens fine in its own thing. But when I double-click, it just opens the worksheet list window, nothing else.

Did you see this? Just curious.

When I use the Sage app itself (not the little menubar item) and do File -> Open File ... then I get the "native" app browser with the worksheet I chose as its title, but nothing else (just a clank browser window. It doesn't do anything, and the worksheet is not there when I check.

Oh you're right. I wonder if that ever worked.

Fixed?

On an unrelated note, why does sage-document-cython.icns look so much bigger than the other icon files?

I made it at a different time and didn't follow the same steps I guess. I fixed this in the patch as well.

Hmm, but it still looks bigger. Probably this isn't a big deal. I can't check what the icons actually look like because I have Xcode as the default to open .pyx files and it won't give me the icon even after saying Sage.app should open them.

By the way, my menubar item never does become blue any more. Maybe that is part of it. I mean, the server is clearly working, so I'm not sure why not. Any ideas?

Okay, I tried it against sage-5.2.beta0 and you are right (when you use the system browser). The problem is the server detection. They changed the (default) pid file of the notebook server. I have fixed this and tested that it also works with the old pid file, and updated the patch.

Okay. What was the change for this?


I'm going to try this out again soon, thanks for the update!

comment:22 in reply to: ↑ 21 ; follow-up: Changed 7 years ago by iandrus

Replying to kcrisman:

Well, it's a little tricky. Double-clicking certainly opens the Sage app, and the notebook server opens, but I don't see it opening the file. Yes, this is on a version of Sage with the sws-cmdline going, because if I open the terminal from within the little dropdown list, I get

sage: notebook(upload="/Users/.../Untitled.sws")
The notebook files are stored in: sage_notebook.sagenb
Another Sage Notebook server is running, PID 19872.
Opening web browser at http://localhost:8000/upload_worksheet?url=file:///Users/.../Untitled.sws ...

and it opens fine in its own thing. But when I double-click, it just opens the worksheet list window, nothing else.

Did you see this? Just curious.

When I use the Sage app itself (not the little menubar item) and do File -> Open File ... then I get the "native" app browser with the worksheet I chose as its title, but nothing else (just a clank browser window. It doesn't do anything, and the worksheet is not there when I check.

Oh you're right. I wonder if that ever worked.

Fixed?

No. It will take some time for me to figure out how to fix it. I haven't looked at it yet.

On an unrelated note, why does sage-document-cython.icns look so much bigger than the other icon files?

I made it at a different time and didn't follow the same steps I guess. I fixed this in the patch as well.

Hmm, but it still looks bigger. Probably this isn't a big deal. I can't check what the icons actually look like because I have Xcode as the default to open .pyx files and it won't give me the icon even after saying Sage.app should open them.

Hmm. It looks the same size to me. Actually, I uploaded the wrong patch. Oops.

You might have to logout and back in to get the icons to change in the Finder.

By the way, my menubar item never does become blue any more. Maybe that is part of it. I mean, the server is clearly working, so I'm not sure why not. Any ideas?

Okay, I tried it against sage-5.2.beta0 and you are right (when you use the system browser). The problem is the server detection. They changed the (default) pid file of the notebook server. I have fixed this and tested that it also works with the old pid file, and updated the patch.

Okay. What was the change for this?

In sage-is-running-on-port.sh. I think it's pretty obvious where the change is. There is also a change in AppController.m, but since I uploaded the wrong patch you wouldn't have been able to see it. :-)

comment:23 in reply to: ↑ 22 ; follow-up: Changed 7 years ago by kcrisman

Fixed?

No. It will take some time for me to figure out how to fix it. I haven't looked at it yet.

Ok. You could just make that functionality raise an error for the time being.

On an unrelated note, why does sage-document-cython.icns look so much bigger than the other icon files?

I made it at a different time and didn't follow the same steps I guess. I fixed this in the patch as well.

Hmm, but it still looks bigger. Probably this isn't a big deal. I can't check what the icons actually look like because I have Xcode as the default to open .pyx files and it won't give me the icon even after saying Sage.app should open them.

Hmm. It looks the same size to me. Actually, I uploaded the wrong patch. Oops.

Well, there we go.

In sage-is-running-on-port.sh. I think it's pretty obvious where the change is. There is also a change in AppController.m, but since I uploaded the wrong patch you wouldn't have been able to see it. :-)

Of course.

comment:24 in reply to: ↑ 23 Changed 7 years ago by iandrus

  • Description modified (diff)

Replying to kcrisman:

Fixed?

No. It will take some time for me to figure out how to fix it. I haven't looked at it yet.

Ok. You could just make that functionality raise an error for the time being.

Okay, it's not too hard to change, but unfortunately, even making it raise an error requires a change to the nib file. Sadly, although the nib files are technically xml, even the tiniest change creates a mountain of changes which almost certainly will conflict with later changes to the nib file. I'll have to rebase all my other patches on top of these changes and it might take me a couple days since I want to be very careful about it.

comment:25 Changed 7 years ago by kcrisman

Yeah, I've noticed this xml constantly changing. Really annoying how opaque this stuff is.

I'll see about the updated patch tonight; I'd rather have you put that on top of other positively reviewed changes, even if that means this gets a sage-pending until that's fixed. Then at least people can test it (and #11056 and #11055). Or? What do you think?

comment:26 follow-up: Changed 7 years ago by kcrisman

Ok, this at least applies correctly. I think I'll even be able to test the "old Sage" thing by using an earlier Sage in it.


Haha! Color is blue! Icon is right size! Worksheet opens (even way before the actual "home page worksheet listing")! Spaces in the name of the worksheet don't matter! "Open With" menu for zip files includes Sage and it works! Opens txt files (though isn't in the options)!


It does get annoying that two new windows open every time when I click on a bunch of worksheets.

Changing the default browser works in that it opens and it tries to get localhost, but it asks for password and of course I haven't got a clue, since it usually just logs in. This happened in both FF and Chrome.

In trying to test with an older Sage version, I drag in a different Sage executable. This works fine. But after I restart Sage.app, the version I dragged in before (where sws-cmdline works) is still there. ?


Anyway, this is much further on the way toward happiness! Given the (less major) issues above, maybe doing the rebasing and fixing the open from file option is better after all.

comment:27 in reply to: ↑ 26 ; follow-up: Changed 7 years ago by iandrus

Replying to kcrisman:

Ok, this at least applies correctly. I think I'll even be able to test the "old Sage" thing by using an earlier Sage in it.


Haha! Color is blue! Icon is right size! Worksheet opens (even way before the actual "home page worksheet listing")! Spaces in the name of the worksheet don't matter! "Open With" menu for zip files includes Sage and it works! Opens txt files (though isn't in the options)!

What do you mean that txt files "aren't in the options"?


It does get annoying that two new windows open every time when I click on a bunch of worksheets.

You mean that the window that logs you in and the window with the worksheet? I agree. I think that requires sagenb changes, but maybe not.

Changing the default browser works in that it opens and it tries to get localhost, but it asks for password and of course I haven't got a clue, since it usually just logs in. This happened in both FF and Chrome.

Hmm. I can't reproduce this with Safari.

In trying to test with an older Sage version, I drag in a different Sage executable. This works fine. But after I restart Sage.app, the version I dragged in before (where sws-cmdline works) is still there. ?

Where do you drag the sage executable? To the preferences window? If so I can confirm that if you do the following it doesn't save

  1. Drag (or otherwise change) the sage executable in the preferences window
  2. Quit _without_ changing focus from the text entry code.

This is because some validation and saving of the value is done when focus is lost. To see what I mean try changing it to a path which doesn't exist and then change focus (e.g. by hitting tab).

I admit this is quite unfortunate, but I think another ticket should be opened for this issue.


Anyway, this is much further on the way toward happiness! Given the (less major) issues above, maybe doing the rebasing and fixing the open from file option is better after all.

I've rebased things and I'll be uploading other patches once I test them a little. For the moment this one is updated.

comment:28 in reply to: ↑ 27 ; follow-ups: Changed 7 years ago by kcrisman

Opens txt files (though isn't in the options)!

What do you mean that txt files "aren't in the options"?

I mean that when I right-click and choose "Open With" that for zip files Sage is in the list, for txt files it isn't. Obvious for sws files it is. But one can still surf through the mini-Finder window and use that, or drag a text file onto the Sage in the Dock (well, I didn't try that, and right now I definitely can't).

You mean that the window that logs you in and the window with the worksheet? I agree. I think that requires sagenb changes, but maybe not.

Fair enough.

Changing the default browser works in that it opens and it tries to get localhost, but it asks for password and of course I haven't got a clue, since it usually just logs in. This happened in both FF and Chrome.

Hmm. I can't reproduce this with Safari.

That's my point. In Safari it's fine, but go into Safari prefs and change the default browser to FF or Chrome, and they don't auto login when you click on a sws file. (That might even be the case without the double click, just when opening Sage - I didn't think to check that.)

In trying to test with an older Sage version, I drag in a different Sage executable. This works fine. But after I restart Sage.app, the version I dragged in before (where sws-cmdline works) is still there. ?

Where do you drag the sage executable? To the preferences window? If so I can confirm that if you do the following it doesn't save

  1. Drag (or otherwise change) the sage executable in the preferences window
  2. Quit _without_ changing focus from the text entry code.

This is because some validation and saving of the value is done when focus is lost. To see what I mean try changing it to a path which doesn't exist and then change focus (e.g. by hitting tab).

I admit this is quite unfortunate, but I think another ticket should be opened for this issue.

That might be the sequence. I was pretty sure that the second time I tried this that I changed the focus by clicking on some of the radio buttons in the prefs, but maybe the "text" focus was still there... I could try this tonight as well.

I've rebased things and I'll be uploading other patches once I test them a little. For the moment this one is updated.

Ok. Updated in the sense that "Open File" now works?

comment:29 in reply to: ↑ 28 Changed 7 years ago by kcrisman

I've rebased things and I'll be uploading other patches once I test them a little. For the moment this one is updated.

Ok. Updated in the sense that "Open File" now works?

Yes!!!

comment:30 in reply to: ↑ 28 ; follow-up: Changed 7 years ago by kcrisman

I mean that when I right-click and choose "Open With" that for zip files Sage is in the list, for txt files it isn't. Obvious for sws files it is. But one can still surf through the mini-Finder window and use that, or drag a text file onto the Sage in the Dock (well, I didn't try that, and right now I definitely can't).

I still get a little flakiness opening txt files. It did work once or twice. Dragging onto the Dock Sage doesn't work.

Changing the default browser works in that it opens and it tries to get localhost, but it asks for password and of course I haven't got a clue, since it usually just logs in. This happened in both FF and Chrome.

Hmm. I can't reproduce this with Safari.

That's my point. In Safari it's fine, but go into Safari prefs and change the default browser to FF or Chrome, and they don't auto login when you click on a sws file. (That might even be the case without the double click, just when opening Sage - I didn't think to check that.)

I can confirm that

  1. Changing the default browser while the Sage app server is running
  2. Trying to use Sage.app by double-clicking an sws file
  3. Leads to login requests at pages with the login screen like
    http://localhost:8000/?next=http%3A%2F%2Flocalhost%3A8000%2Fupload_worksheet%3Furl%3Dfile%3A%2F%2Flocalhost%2FUsers...%2Ftest.txt
    

The only way I got it to log in by itself was by asking it to upload a worksheet; apparently that confused it enough that it logged me in for the "extra window" with the worksheet list, but not for the actual uploaded guy. That only worked once, though.

But apparently it works ok if you turn off the server first. I think? What do you think, is this a bug? At least I figured out what was going on. Because of the way it works, I'm inclined to let it go for now, or at most to ask for some clarifying addition to documentation.


So the moral of the story is that I like this overall. Can you think of something else I should try in breaking this? I also tested with an older binary and it still works that way.

Unfortunately the new diff is too big for preview :( Reading through it, it seems like there is a lot more of stuff like

+				<object class="IBConnectionRecord">
+					<object class="IBActionConnection" key="connection">
+						<string key="label">viewSageLog:</string>
+						<reference key="source" ref="57092200"/>
+						<reference key="destination" ref="112170745"/>
+					</object>
+					<int key="connectionID">1686</int>
+				</object>

and

+					<string>com.apple.InterfaceBuilder.CocoaPlugin</string>
+					<string>com.apple.InterfaceBuilder.CocoaPlugin</string>
+					<string>com.apple.InterfaceBuilder.CocoaPlugin</string>
+					<string>com.apple.InterfaceBuilder.CocoaPlugin</string>
+					<string>com.apple.InterfaceBuilder.CocoaPlugin</string>

than in the other patches. Is there a good reason why the patch is nearly twice as big for this stuff?

Anyway, this is looking quite good now. Thanks for all this hard work.


On a totally unrelated note, you might be interested in this ask.sagemath question since it only seems to happen on the Mac app.

comment:31 in reply to: ↑ 30 ; follow-up: Changed 7 years ago by iandrus

Replying to kcrisman:

I mean that when I right-click and choose "Open With" that for zip files Sage is in the list, for txt files it isn't. Obvious for sws files it is. But one can still surf through the mini-Finder window and use that, or drag a text file onto the Sage in the Dock (well, I didn't try that, and right now I definitely can't).

I still get a little flakiness opening txt files. It did work once or twice. Dragging onto the Dock Sage doesn't work.

That should be fixed now.

Changing the default browser works in that it opens and it tries to get localhost, but it asks for password and of course I haven't got a clue, since it usually just logs in. This happened in both FF and Chrome.

Hmm. I can't reproduce this with Safari.

That's my point. In Safari it's fine, but go into Safari prefs and change the default browser to FF or Chrome, and they don't auto login when you click on a sws file. (That might even be the case without the double click, just when opening Sage - I didn't think to check that.)

I can confirm that

  1. Changing the default browser while the Sage app server is running
  2. Trying to use Sage.app by double-clicking an sws file
  3. Leads to login requests at pages with the login screen like
    http://localhost:8000/?next=http%3A%2F%2Flocalhost%3A8000%2Fupload_worksheet%3Furl%3Dfile%3A%2F%2Flocalhost%2FUsers...%2Ftest.txt
    

The only way I got it to log in by itself was by asking it to upload a worksheet; apparently that confused it enough that it logged me in for the "extra window" with the worksheet list, but not for the actual uploaded guy. That only worked once, though.

But apparently it works ok if you turn off the server first. I think? What do you think, is this a bug? At least I figured out what was going on. Because of the way it works, I'm inclined to let it go for now, or at most to ask for some clarifying addition to documentation.

Ah, yes that makes sense. If you switch the default browser in the middle there is no way for Sage to know that you need it to log in automatically except by restarting the server. The same would happen if you logged out explicitly. I'm not sure if this is possible to fix since I think the login token is only generated when the server is started. I could be completely wrong about that, but I think we should probably create a new ticket for this since it will almost certainly require changes to sagenb.


So the moral of the story is that I like this overall. Can you think of something else I should try in breaking this? I also tested with an older binary and it still works that way.

I think you've broken it pretty good. :-) I can't think of anything else to test, except perhaps zip files (if you haven't tested those already). And of course on different operating systems.

Unfortunately the new diff is too big for preview :( Reading through it, it seems like there is a lot more of stuff like

+				<object class="IBConnectionRecord">
+					<object class="IBActionConnection" key="connection">
+						<string key="label">viewSageLog:</string>
+						<reference key="source" ref="57092200"/>
+						<reference key="destination" ref="112170745"/>
+					</object>
+					<int key="connectionID">1686</int>
+				</object>

and

+					<string>com.apple.InterfaceBuilder.CocoaPlugin</string>
+					<string>com.apple.InterfaceBuilder.CocoaPlugin</string>
+					<string>com.apple.InterfaceBuilder.CocoaPlugin</string>
+					<string>com.apple.InterfaceBuilder.CocoaPlugin</string>
+					<string>com.apple.InterfaceBuilder.CocoaPlugin</string>

than in the other patches. Is there a good reason why the patch is nearly twice as big for this stuff?

I'm using a new version of Xcode and so it thinks it needs to rearrange everything. It's very frustrating to me, but I don't think there is much I can do short of editing the file manually which scares me. Sometimes I with nib files were still binary since they basically have to be treated as such.

Anyway, this is looking quite good now. Thanks for all this hard work.

Finally, eh? :-)

Changed 7 years ago by iandrus

comment:32 in reply to: ↑ 31 Changed 7 years ago by kcrisman

I still get a little flakiness opening txt files. It did work once or twice. Dragging onto the Dock Sage doesn't work.

That should be fixed now.

Okay, I'll try that later.

Ah, yes that makes sense. If you switch the default browser in the middle there is no way for Sage to know that you need it to log in automatically except by restarting the server. The same would happen if you logged out explicitly. I'm not sure if this is possible to fix since I think the login token is only generated when the server is started. I could be completely wrong about that, but I think we should probably create a new ticket for this since it will almost certainly require changes to sagenb.

Ok.

I think you've broken it pretty good. :-) I can't think of anything else to test, except perhaps zip files (if you haven't tested those already). And of course on different operating systems.

I've thus far only tested on Snow Leopard. I do not have access (yet) to a Lion machine, though I will probably get one by the end of the month (and have to turn this one in). I will be able to test on Tiger sometime in the next few days.

comment:33 follow-up: Changed 7 years ago by kcrisman

Text file now has Sage as an option to open (among like 20 possibilities!) and works fine.

I can't think of anything else to test, except perhaps zip files (if you haven't tested those already).

Oh, and I did test these already. Interestingly, when opening a zip from its icon, you get to see that they are added somehow, but they are just silently uploaded from the File -> Open dialogue.

This is really working great. I'm very pleased. Now if only we could get the same thing happening on Windows! I don't think the virtual machine solution is quite ready for that yet.

And of course on different operating systems.

You know, I thought of a reason for putting this Xcode project on bitbucket or something - it means I could just download that to test new things with it on an older machine, as opposed to having to build a Sage from scratch to do so. For this I needed the new sagenb anyway, so the easiest way to do that is get 5.2.beta0 and build, but of course that isn't always so nice. Also, it was really hard for me to tell what had changed between your different versions sometimes.

I can't believe I'm arguing in favor of a revision control system, on the web, no less. There must be a reason your email has a Darth in it...

comment:34 in reply to: ↑ 33 Changed 7 years ago by iandrus

Replying to kcrisman:

And of course on different operating systems.

You know, I thought of a reason for putting this Xcode project on bitbucket or something - it means I could just download that to test new things with it on an older machine, as opposed to having to build a Sage from scratch to do so. For this I needed the new sagenb anyway, so the easiest way to do that is get 5.2.beta0 and build, but of course that isn't always so nice. Also, it was really hard for me to tell what had changed between your different versions sometimes.

I would be open to that.

I can't believe I'm arguing in favor of a revision control system, on the web, no less. There must be a reason your email has a Darth in it...

:-) I have hg set up to play "Don't be too proud of this technological terror you've constructed" every time I commit.

comment:35 follow-up: Changed 7 years ago by kcrisman

On Tiger, I do indeed need to do the universal cross-develop as I think the readme directs. I get two warnings for implicit declaration of sleep, and two for webview perhaps not responding to isloading. Whatever?

On the plus side, the new intro screen is nicer! (I'm doing it with 5.2.beta0 on this computer.) Asks for an executable well.

I'm having trouble even getting previously existing functionality to work this way, though. I get, for http://localhost:8000/new_worksheet, "Not Found The resource /new_worksheet cannot be found." when doing "New worksheet" from the Sage menu item, and "Open Notebook" doesn't have the login. (Though when I initially start the app it does do automatic login.) I also had the trouble with the Mac app skeleton in the sage-5.2.beta0 binary conflicting with the one I built.

And now even trouble with the regular login, on clicking on an sws

Safari can’t open the page “http://localhost:8000/?startup_token=64130e35bb235d83b5337f2a920eae0f” because Safari can’t connect to the server “localhost”.

and

The resource /upload_worksheet?url=file://localhost/Users/crisman/Desktop/Untitled.sws cannot be found.

But then stopping everything, quitting Sage.app, and restarting (without double-clicking) gives me the Sage server - at port 8001! And works ok. But not the stuff on this ticket.

There was an error uploading 'file://localhost/Users/crisman/Desktop/Untitled.sws' (please recheck the URL). Return to Upload File.

which was from the URL

http://localhost:8001/upload_worksheet?url=file://localhost/Users/crisman/Desktop/Untitled.sws

I have to admit that because of the above problem with the phantom Sage.app I had two Sage servers running... so after killing both python processes, I tried again and got THREE open windows. One with a normal worksheet list; one with a login token URL with an error message, and one with the error message in the browser about an invalid URL for the upload itself.

2012-07-13 22:32:33-0400 [HTTPChannel,3,127.0.0.1] Exception rendering:
2012-07-13 22:32:33-0400 [HTTPChannel,3,127.0.0.1] Unhandled Error
	Traceback (most recent call last):
	Failure: twisted.python.failure.DefaultException: Bad token
	

among other error message in sage.log.

The more I try, the weirder it gets, including a server running but with a gray menu icon, more stuff running on port 8001, ... anyway, it's certainly not behaving consistently, and I have yet to get it to upload a worksheet on Tiger. It could all be because of having multiple Sage.apps, but this is even after I dump the phantom ones (skeleton) in the Trash.

I could try doing a bdist next and dumping everything else in the Trash, but that seems a little drastic. Especially since I only have 1.34 GB left free on the device!

Now, some of these problems turn out to been caused by using the wrong binary at first. And I did finally upload a file by clicking it! But some of the issues are still around - gray icon even though there is (at least one) server running, intro splash screen continuing to show up even though already running server, using extra ports even after killing processes, logging in too fast after starting the server - aack! Seems like even properly shutting down the server and quitting the app don't remove these extra python2.7 processes, I have to kill them by hand.

So maybe the warnings about sleep and webview weren't wrong! I could, as a non-expert, think of interpretations for some of what is happening in terms of the natural English meaning of those words.

If you have some advice, that would be helpful. We could also reasonably say "this doesn't work on Tiger reliably", I suppose, because it's an enhancement, but I don't really see what Tiger has to do with this.

Last edited 7 years ago by kcrisman (previous) (diff)

comment:36 in reply to: ↑ 35 Changed 7 years ago by iandrus

Replying to kcrisman:

On Tiger, I do indeed need to do the universal cross-develop as I think the readme directs. I get two warnings for implicit declaration of sleep, and two for webview perhaps not responding to isloading. Whatever?

Actually, this could be part or all of the program. Supposedly the isLoading method is available on Mac OS X v10.4.11 and later. I do check whether it's available, and if it's not available I just sleep for 1 second instead of waiting. I think this might cause it to think the server has started when it really hasn't yet. I assumed it would never actually happen, since I thought most people would be on 10.4.11. It's possible that you have a slightly out of date SDK, or just that it issues the warning. More worrisome to me is the warning for implicit declaration of sleep, because that means some header didn't get included and then even the sleep might not work.

You could try adding

#import <Foundation/Foundation.h>

to the top of AppDelegate.m and see if that fixes the sleep warning.

Anyway all this is related to detection of whether the server is running, but only if you are using Sage.app as the browser. Now that I think about it, I don't think you can use Sage.app as the browser on Tiger, so that shouldn't be the problem.

On the plus side, the new intro screen is nicer! (I'm doing it with 5.2.beta0 on this computer.) Asks for an executable well.

I'm having trouble even getting previously existing functionality to work this way, though. I get, for http://localhost:8000/new_worksheet, "Not Found The resource /new_worksheet cannot be found." when doing "New worksheet" from the Sage menu item, and "Open Notebook" doesn't have the login. (Though when I initially start the app it does do automatic login.) I also had the trouble with the Mac app skeleton in the sage-5.2.beta0 binary conflicting with the one I built.

And now even trouble with the regular login, on clicking on an sws

Safari can’t open the page “http://localhost:8000/?startup_token=64130e35bb235d83b5337f2a920eae0f” because Safari can’t connect to the server “localhost”.

and

The resource /upload_worksheet?url=file://localhost/Users/crisman/Desktop/Untitled.sws cannot be found.

This sounds like the server isn't running, or isn't running correctly. Maybe it's running on a different port or something?

But then stopping everything, quitting Sage.app, and restarting (without double-clicking) gives me the Sage server - at port 8001! And works ok. But not the stuff on this ticket.

There was an error uploading 'file://localhost/Users/crisman/Desktop/Untitled.sws' (please recheck the URL). Return to Upload File.

which was from the URL

http://localhost:8001/upload_worksheet?url=file://localhost/Users/crisman/Desktop/Untitled.sws

That sounds like you're using an old version of the sage server. What version does it say on the Notebook page under the Sage logo in the upper left?

I have to admit that because of the above problem with the phantom Sage.app I had two Sage servers running... so after killing both python processes, I tried again and got THREE open windows. One with a normal worksheet list; one with a login token URL with an error message, and one with the error message in the browser about an invalid URL for the upload itself.

2012-07-13 22:32:33-0400 [HTTPChannel,3,127.0.0.1] Exception rendering:
2012-07-13 22:32:33-0400 [HTTPChannel,3,127.0.0.1] Unhandled Error
	Traceback (most recent call last):
	Failure: twisted.python.failure.DefaultException: Bad token
	

among other error message in sage.log.

Hmm. I'm not sure what might cause a "Bad token" error. There is #2935 which might or might not be related. It seems to have about the same level of weirdness. :-) There is a work around there. Well, for whatever Jaap's problem was which is probably not the same problem you are having.

The more I try, the weirder it gets, including a server running but with a gray menu icon, more stuff running on port 8001, ... anyway, it's certainly not behaving consistently, and I have yet to get it to upload a worksheet on Tiger. It could all be because of having multiple Sage.apps, but this is even after I dump the phantom ones (skeleton) in the Trash.

Just a wild guess, but maybe you have something other than Sage running on port 8000.

I could try doing a bdist next and dumping everything else in the Trash, but that seems a little drastic. Especially since I only have 1.34 GB left free on the device!

Now, some of these problems turn out to been caused by using the wrong binary at first. And I did finally upload a file by clicking it! But some of the issues are still around - gray icon even though there is (at least one) server running, intro splash screen continuing to show up even though already running server, using extra ports even after killing processes, logging in too fast after starting the server - aack! Seems like even properly shutting down the server and quitting the app don't remove these extra python2.7 processes, I have to kill them by hand.

I think the main problem is it doesn't detect the running server. That is what the grey icon means, and it will continue to try starting the server thereby putting up the splash screen etc. It also won't shut the server down. So the question is why doesn't it know that a server is started. If you start a server from the command line and then launch Sage.app does it recognize it? You can try running Sage.app/Contents/Resources/sage-is-running-on-port.sh by hand to see what it says. Does it even turn green when tell it to start the server?

So maybe the warnings about sleep and webview weren't wrong! I could, as a non-expert, think of interpretations for some of what is happening in terms of the natural English meaning of those words.

If you have some advice, that would be helpful. We could also reasonably say "this doesn't work on Tiger reliably", I suppose, because it's an enhancement, but I don't really see what Tiger has to do with this.

Tiger doesn't have all of the capabilities of later operating systems. For example it doesn't work to show up in the Dock (did I document that somewhere...). So it's conceivable it's a Tiger only issue.

I guess my advice would be to reboot and start completely fresh. Maybe drink your favorite beverage. :-)

Thanks again for all the testing. I really wish I had access to a 10.4 machine.

comment:37 follow-up: Changed 7 years ago by kcrisman

Okay, I did a bunch more testing on this box. It works fine but very slow as long as you start Sage.app first. I have more trouble if I do the click first - it seems to start two servers and gives errors. This is a reproducible sequence.

Traceback (most recent call last):
  File "/Users/crisman/Desktop/sage-5.2.beta0/local/bin/sage-notebook", line 36, in <module>
    notebook(port=8000)
  File "/Users/crisman/Desktop/sage-5.2.beta0/devel/sagenb/sagenb/notebook/notebook_object.py", line 206, in __call__
    return self.notebook(*args, **kwds)
  File "/Users/crisman/Desktop/sage-5.2.beta0/devel/sagenb/sagenb/notebook/run_notebook.py", line 434, in notebook_twisted
    return run(port)
  File "/Users/crisman/Desktop/sage-5.2.beta0/devel/sagenb/sagenb/notebook/run_notebook.py", line 419, in run
    raise socket.error
socket.error

Once this happens, then subsequent login attempts cause me to have to log in to get to see the sheets.

So we could add a very careful set of instructions to try to warn people to avoid this situation. I mean, it does work. Just not ideally.


By the way, switching my default browser to the Sage.app one worked fine :)


I'm going to try the

#import <Foundation/Foundation.h>

trick now in a rebuilt app and see what happens.

Didn't seem to help; I got the same

/Users/crisman/Desktop/sage-5.2.beta0/data/extcode/sage/ext/mac-app/AppDelegate.m:189: warning: (Messages without a matching method signature will be assumed to return 'id' and accept '...' as arguments.)

and the sleep warning, twice each. Would it matter where I put that import in the top few lines? I tried it at the end and the middle, same thing both times.

comment:38 in reply to: ↑ 37 ; follow-up: Changed 7 years ago by iandrus

Replying to kcrisman:

Okay, I did a bunch more testing on this box. It works fine but very slow as long as you start Sage.app first. I have more trouble if I do the click first - it seems to start two servers and gives errors. This is a reproducible sequence.

Traceback (most recent call last):
  File "/Users/crisman/Desktop/sage-5.2.beta0/local/bin/sage-notebook", line 36, in <module>
    notebook(port=8000)
  File "/Users/crisman/Desktop/sage-5.2.beta0/devel/sagenb/sagenb/notebook/notebook_object.py", line 206, in __call__
    return self.notebook(*args, **kwds)
  File "/Users/crisman/Desktop/sage-5.2.beta0/devel/sagenb/sagenb/notebook/run_notebook.py", line 434, in notebook_twisted
    return run(port)
  File "/Users/crisman/Desktop/sage-5.2.beta0/devel/sagenb/sagenb/notebook/run_notebook.py", line 419, in run
    raise socket.error
socket.error

Once this happens, then subsequent login attempts cause me to have to log in to get to see the sheets.

What if you quite Sage.app and start it again. Does it recognize that a server is running? Is one running? If quitting stops both servers, then try holding Option when you quit to not kill the server and see if Sage.app recognizes the server then.

What happens (i.e. does it work okay) if you start the server yourself from the command line, and then double click a sws file (without Sage.app being open)? Does 5.2.beta0 use the new notebook?

So we could add a very careful set of instructions to try to warn people to avoid this situation. I mean, it does work. Just not ideally.

I'd like to get this fixed since it's supposed to work, but I guess it depends on how long we have to wait for me to fix it. It's not going into 5.2 though so we have some time. I can't reproduce the problem so it might be a timing issue. I'll try to look at the code and see if I can figure it out.


By the way, switching my default browser to the Sage.app one worked fine :)

You mean, that you don't see the above problems, or just that it works in other ways?


I'm going to try the

#import <Foundation/Foundation.h>

trick now in a rebuilt app and see what happens.

Didn't seem to help; I got the same

/Users/crisman/Desktop/sage-5.2.beta0/data/extcode/sage/ext/mac-app/AppDelegate.m:189: warning: (Messages without a matching method signature will be assumed to return 'id' and accept '...' as arguments.)

and the sleep warning, twice each. Would it matter where I put that import in the top few lines? I tried it at the end and the middle, same thing both times.

No, where you put it shouldn't matter.

comment:39 in reply to: ↑ 38 ; follow-up: Changed 7 years ago by kcrisman

What if you quite Sage.app and start it again. Does it recognize that a server is running? Is one running? If quitting stops both servers, then try holding Option when you quit to not kill the server and see if Sage.app recognizes the server then.

What happens (i.e. does it work okay) if you start the server yourself from the command line, and then double click a sws file (without Sage.app being open)? Does 5.2.beta0 use the new notebook?

Whew! I can't do this all immediately. Yes, it should use the new notebook.

I'd like to get this fixed since it's supposed to work, but I guess it depends on how long we have to wait for me to fix it. It's not going into 5.2 though so we have some time. I can't reproduce the problem so it might be a timing issue. I'll try to look at the code and see if I can figure it out.

ok.

You mean, that you don't see the above problems, or just that it works in other ways?

Just that it works. I didn't bother checking all this, I'm sure it wouldn't be better.

comment:40 in reply to: ↑ 39 Changed 7 years ago by kcrisman

What if you quite Sage.app and start it again. Does it recognize that a server is running? Is one running? If quitting stops both servers, then try holding Option when you quit to not kill the server and see if Sage.app recognizes the server then.

If I click before starting Sage.app (this is the case we are talking about here), I get the two servers. As far as I can tell, maybe even neither one is stopped when I quit! But ps just gives one... anyway, when I then start Sage.app normally, I get the gray icon, but I get a new server starting on port 8001.

I think that what happens is that there shouldn't be any processes listed for me under ps because they are not owned by me in the Terminal. But someone one is. The 8001 process doesn't show up in ps.

  493  ??  Ss     0:00.05 /bin/bash /Users/crisman/Desktop/Sage-click.app/Contents/Resources/start-sage.sh /User
  558  ??  S      0:00.38 python /Users/crisman/Desktop/sage-5.2.beta0/local/bin/sage-cleaner
  560  ??  S      0:00.02 bash ./sage --notebook
  562  ??  S      0:00.04 bash /Users/crisman/Desktop/sage-5.2.beta0/spkg/bin/sage --notebook
  566  ??  S      0:06.36 python /Users/crisman/Desktop/sage-5.2.beta0/local/bin/sage-notebook
  582  ??  S      0:11.62 python /Users/crisman/Desktop/sage-5.2.beta0/local/bin/twistd --pidfile=sage_notebook.
  644  ??  S      0:00.61 /Users/crisman/Desktop/Sage-click.app/Contents/MacOS/Sage -psn_0_5898241
  645  ??  Ss     0:00.05 /bin/bash /Users/crisman/Desktop/Sage-click.app/Contents/Resources/start-sage.sh /User
  675  ??  S      0:00.02 bash ./sage --notebook
  677  ??  S      0:00.04 bash /Users/crisman/Desktop/sage-5.2.beta0/spkg/bin/sage --notebook
  681  ??  S      0:06.40 python /Users/crisman/Desktop/sage-5.2.beta0/local/bin/sage-notebook
  682  ??  S      0:08.83 python /Users/crisman/Desktop/sage-5.2.beta0/local/bin/twistd --pidfile=sage_notebook.
  700  ??  S      0:02.18 /Applications/Utilities/Console.app/Contents/MacOS/Console -psn_0_6160385
  488  p1  Ss     0:00.02 login -pf crisman
  489  p1  S      0:00.04 -bash
  714  p1  R+     0:00.01 ps -A
  632  p2  Ss+    0:00.20 /Users/crisman/Desktop/sage-5.2.beta0/local/bin/python

As you can see, there are at least two full Sage servers going on now.

What happens (i.e. does it work okay) if you start the server yourself from the command line, and then double click a sws file (without Sage.app being open)?

This seems to work okay. There still is the extra worksheet list window opening late, but that is acceptable - no other server is started. By the way, quitting the Sage server in the little menubar item stops it in the Terminal too, which is good (in this scenario).

I'd like to get this fixed since it's supposed to work, but I guess it depends on how long we have to wait for me to fix it. It's not going into 5.2 though so we have some time. I can't reproduce the problem so it might be a timing issue. I'll try to look at the code and see if I can figure it out.

Again, given that Tiger is a much older platform, good instructions for how to use it properly might be good enough. It does work, just not optimally. May have to include instructions on how to use Activity Monitor or something to close processes... I'd really like to see this on Leopard, since that is a more likely platform to still be in use for a situation that requires double-clicks... though who knows? I think there are more people using old Macs than we think out there.


Is there anybody out there who could try this on Lion?

Last edited 7 years ago by kcrisman (previous) (diff)

comment:41 Changed 7 years ago by kcrisman

I have Lion now. Hopefully I'll someday finish reviewing this...

comment:42 follow-up: Changed 7 years ago by nkirchner

I'm on OS X Lion.

This patch does start and stop the server. Starting the server initializes three python2.7 processes. Two of them are ~100MB and one is ~5MB. Stopping the server or exiting Sage.app terminates the two larger of these, while leaving the ~5MB python2.7 process running. This last running process is a problem for deleting/renaming Sage.app, and does not go away on its own.

Telling Sage.app to start a terminal session also spawns a ~5MB python2.7 process which persists after exiting both that terminal session and Sage.app.

Right-clicking a .txt file and selecting Sage.app to open it results in the text of the file being placed above the first input cell without linebreaks. That is, a text file consisting of

"""Hello. I'm a
sample text file in Sage.app"""

ends up being opened with the text "Hello. I'm a sample text file in Sage.app", with the first input cell following the text. I've not yet tried it with a proper text Sage worksheet.

Double-clicking a .sws file saved via Sage.app's File->Save As menu does activate Sage.app. It pulls up an error page:

"There was an error uploading the worksheet. It could be an old unsupported format or worse. If you desperately need its contents contact the sage-support group and post a link to your worksheet. Alternatively, an sws file is just a bzip2 tarball; take a look inside!"

Instead using the in-browser's File->Save worksheet to file... does not appear to save anything.

Using Firefox instead, I can save an sws file and open it by double clicking. I'm testing this functionality further right now.

comment:43 in reply to: ↑ 42 Changed 7 years ago by iandrus

Replying to nkirchner:

I'm on OS X Lion.

This patch does start and stop the server. Starting the server initializes three python2.7 processes. Two of them are ~100MB and one is ~5MB. Stopping the server or exiting Sage.app terminates the two larger of these, while leaving the ~5MB python2.7 process running. This last running process is a problem for deleting/renaming Sage.app, and does not go away on its own.

I think that is a sage-cleaner process, and it _should_ go away. You can check what process it is by running in a terminal

ps aux | grep PID

where you can get the PID from Activity Monitor (left most column).

Does this happen every time you start the server, thereby accumulating a new process every time?

Telling Sage.app to start a terminal session also spawns a ~5MB python2.7 process which persists after exiting both that terminal session and Sage.app.

When I open a terminal session, I only see one python2.7 process, using about 113MB of memory. After exiting the session the process terminates. Maybe there is something about your system that causes sage-cleaner to hang around, or perhaps the difference is due to different Sage versions. What version are you using? I'm actually still using 5.4.rc2 with some patches e.g. for new ipython.

Right-clicking a .txt file and selecting Sage.app to open it results in the text of the file being placed above the first input cell without linebreaks. That is, a text file consisting of

"""Hello. I'm a
sample text file in Sage.app"""

ends up being opened with the text "Hello. I'm a sample text file in Sage.app", with the first input cell following the text. I've not yet tried it with a proper text Sage worksheet.

Cool.

Double-clicking a .sws file saved via Sage.app's File->Save As menu does activate Sage.app. It pulls up an error page:

"There was an error uploading the worksheet. It could be an old unsupported format or worse. If you desperately need its contents contact the sage-support group and post a link to your worksheet. Alternatively, an sws file is just a bzip2 tarball; take a look inside!"

This is because the File -> Save As doesn't work. I have already removed it in another patch. Sadly, it touches a nib file (which are virtually unmergeable) so I would rather not add that same change here since all further changes would have to be rebased.

Instead using the in-browser's File->Save worksheet to file... does not appear to save anything.

I have opened #13931 for this.

Using Firefox instead, I can save an sws file and open it by double clicking. I'm testing this functionality further right now.

Awesome. Thanks.

For reference, some of this discussion also took place on the mailing list.

comment:44 follow-up: Changed 7 years ago by nkirchner

On OS X Lion, running Sage 5.5 compiled from source.

Notes on lingering process after stopping server:

ps aux | grep (process id) reveals it's sage-cleaner. The process persists for at least six hours. I'm looking into this further, and think it's a separate issue from Sage.app: I had previously observed that running sage from a terminal did not spawn a lingering process, but that has changed. Running sage from terminal also creates a sage-cleaner process.

About the opening of files:

On opening up documents by double clicking or right-clicking and selecting Open With..., I have found that compressed .sws (.sws.zip) files do not open. Text files open fine... I had the enigmatic title "{{{id=9|" in my test case, but all the cells imported just fine. Compressed text (.txt.zip) does the same thing as non-compressed text.

Opening with .sws format also preserves output cells, including graphics. Opening .txt files preserves non-graphical output cells.

One issue I came across with the opening of files: With Sage.app running, but the server not active, opening a .txt file via Open With... -> Sage.app did not work. I resolved this by noting that my sage.log complained "Worksheet admin/xx does not exist". Deleting the ~/.sage/sagenb.../admin/xx folder fixed the problem and the text file opened fine.

Otherwise, when instructing Sage.app to open files, it does not matter whether the server is running, or Sage.app is running. Sage.app will open and start the server as necessary and open up the files.

comment:45 in reply to: ↑ 44 Changed 7 years ago by iandrus

Replying to nkirchner:

On OS X Lion, running Sage 5.5 compiled from source.

Notes on lingering process after stopping server:

ps aux | grep (process id) reveals it's sage-cleaner. The process persists for at least six hours. I'm looking into this further, and think it's a separate issue from Sage.app: I had previously observed that running sage from a terminal did not spawn a lingering process, but that has changed. Running sage from terminal also creates a sage-cleaner process.

I agree it's _probably_ a separate issue. But it's often hard to tell.

About the opening of files:

On opening up documents by double clicking or right-clicking and selecting Open With..., I have found that compressed .sws (.sws.zip) files do not open. Text files open fine... I had the enigmatic title "{{{id=9|" in my test case, but all the cells imported just fine. Compressed text (.txt.zip) does the same thing as non-compressed text.

Opening with .sws format also preserves output cells, including graphics. Opening .txt files preserves non-graphical output cells.

Uploading like this should work exactly like uploading from the interface. I would have thought that .sws.zip files would work, but I can't swear that I tested it. I will do it later tonight.

One issue I came across with the opening of files: With Sage.app running, but the server not active, opening a .txt file via Open With... -> Sage.app did not work. I resolved this by noting that my sage.log complained "Worksheet admin/xx does not exist". Deleting the ~/.sage/sagenb.../admin/xx folder fixed the problem and the text file opened fine.

I have seen this before (complaining about worksheets not existing). I don't know if it's related to Sage.app (I suspect not), but I haven't been able to replicate it reliably. If you have a replication path that would be great (and probably a separate trac ticket).

After you deleted that, were you able to open the text file with the server not active?

Otherwise, when instructing Sage.app to open files, it does not matter whether the server is running, or Sage.app is running. Sage.app will open and start the server as necessary and open up the files.

Excellent.

comment:46 follow-up: Changed 7 years ago by nkirchner

  • Status changed from needs_review to positive_review

I deleted my ~/.sage folder. This fixed the lingering sage-cleaner process problem, so that's no longer an issue.

When trying to open a .sws.zip file with no server running, Sage.app will start the server twice for some reason. sage.log gives no error message indicating why it needs to start a second time. Doing the same with a .txt.zip file will import the worksheet, but not open it--instead the .txt.zip file becomes the top item in the list of active worksheets (which is acceptable behavior, probably). .sws and .txt files are both imported and opened.

Attempting to upload a .sws.zip file from the sagenb interface results in the error "There was an error uploading the worksheet. It could be an old unsupported format or worse. If you desperately need its contents contact the sage-support group and post a link to your worksheet. Alternatively, an sws file is just a bzip2 tarball; take a look inside!" The problem with .sws.zip files seems to be outside the scope of this patch.

I think I'll go ahead with the positive review here. The only issue relevant to this patch is the .txt.zip issue, and that's merely slightly suboptimal and not a real problem.

comment:47 follow-ups: Changed 7 years ago by kcrisman

  • Reviewers changed from Karl-Dieter Crisman to Karl-Dieter Crisman, Nicholas Kirchner
  • Status changed from positive_review to needs_info

I would like to try this on an older Mac again if possible, to make sure I no longer see the problems I had in the past. Have you been using OS X 10.8? I have access to 10.7 and 10.4. But in general thanks for your great review! By the way, you can add yourself to the list of developers on Trac if you want...

comment:48 Changed 7 years ago by kcrisman

  • Dependencies #8473, #13121 deleted

comment:49 in reply to: ↑ 47 Changed 7 years ago by nkirchner

Replying to kcrisman:

I would like to try this on an older Mac again if possible, to make sure I no longer see the problems I had in the past. Have you been using OS X 10.8? I have access to 10.7 and 10.4. But in general thanks for your great review! By the way, you can add yourself to the list of developers on Trac if you want...

I've been working an OS X 10.7 and sage 5.5. I have no other macs to try it on.

comment:50 in reply to: ↑ 47 Changed 7 years ago by iandrus

Replying to kcrisman:

I would like to try this on an older Mac again if possible, to make sure I no longer see the problems I had in the past. Have you been using OS X 10.8? I have access to 10.7 and 10.4. But in general thanks for your great review! By the way, you can add yourself to the list of developers on Trac if you want...

I've been using 10.8 (for the past few months or so). It would be great to test it on 10.4 since it seems very different from 10.5 and later versions.

comment:51 in reply to: ↑ 46 ; follow-up: Changed 7 years ago by iandrus

Replying to nkirchner:

I deleted my ~/.sage folder. This fixed the lingering sage-cleaner process problem, so that's no longer an issue.

When trying to open a .sws.zip file with no server running, Sage.app will start the server twice for some reason. sage.log gives no error message indicating why it needs to start a second time.

Is this reproducible? I just tried it, and didn't see that behavior, so it may be a timing issue somewhere (which would be nice to find, but potentially quite hard).

Doing the same with a .txt.zip file will import the worksheet, but not open it--instead the .txt.zip file becomes the top item in the list of active worksheets (which is acceptable behavior, probably). .sws and .txt files are both imported and opened.

I just checked the notebook code and it doesn't open the worksheet in a zip file because there can be many of them in the zip file so it doesn't know which one to open.

Attempting to upload a .sws.zip file from the sagenb interface results in the error "There was an error uploading the worksheet. It could be an old unsupported format or worse. If you desperately need its contents contact the sage-support group and post a link to your worksheet. Alternatively, an sws file is just a bzip2 tarball; take a look inside!" The problem with .sws.zip files seems to be outside the scope of this patch.

I think I'll go ahead with the positive review here. The only issue relevant to this patch is the .txt.zip issue, and that's merely slightly suboptimal and not a real problem.

comment:52 in reply to: ↑ 51 ; follow-up: Changed 7 years ago by nkirchner

Replying to iandrus:

Replying to nkirchner:

I deleted my ~/.sage folder. This fixed the lingering sage-cleaner process problem, so that's no longer an issue.

When trying to open a .sws.zip file with no server running, Sage.app will start the server twice for some reason. sage.log gives no error message indicating why it needs to start a second time.

Is this reproducible? I just tried it, and didn't see that behavior, so it may be a timing issue somewhere (which would be nice to find, but potentially quite hard).

It was reproducible when I had the line

export SAGE_ROOT="/Applications/Sage.app/Contents/Resources/sage"

in my ~/.bashrc. Changing the line to

export SAGE_ROOT="/Applications/Sage.app/Contents/Resources/sage/"

resulted in different behavior: Server opens once and pops up a window with the error message mentioned previously.

Doing the same with a .txt.zip file will import the worksheet, but not open it--instead the .txt.zip file becomes the top item in the list of active worksheets (which is acceptable behavior, probably). .sws and .txt files are both imported and opened.

I just checked the notebook code and it doesn't open the worksheet in a zip file because there can be many of them in the zip file so it doesn't know which one to open.

My test case has one .sws file in it.

comment:53 in reply to: ↑ 52 ; follow-up: Changed 7 years ago by iandrus

Replying to nkirchner:

Replying to iandrus:

Replying to nkirchner:

I deleted my ~/.sage folder. This fixed the lingering sage-cleaner process problem, so that's no longer an issue.

When trying to open a .sws.zip file with no server running, Sage.app will start the server twice for some reason. sage.log gives no error message indicating why it needs to start a second time.

Is this reproducible? I just tried it, and didn't see that behavior, so it may be a timing issue somewhere (which would be nice to find, but potentially quite hard).

It was reproducible when I had the line

export SAGE_ROOT="/Applications/Sage.app/Contents/Resources/sage"

in my ~/.bashrc. Changing the line to

export SAGE_ROOT="/Applications/Sage.app/Contents/Resources/sage/"

resulted in different behavior: Server opens once and pops up a window with the error message mentioned previously.

The second is what I saw. However, unless I am mistaken, you should not be setting SAGE_ROOT. You shouldn't need to, and IIRC it can lead to problems.

Doing the same with a .txt.zip file will import the worksheet, but not open it--instead the .txt.zip file becomes the top item in the list of active worksheets (which is acceptable behavior, probably). .sws and .txt files are both imported and opened.

I just checked the notebook code and it doesn't open the worksheet in a zip file because there can be many of them in the zip file so it doesn't know which one to open.

My test case has one .sws file in it.

Yes, but the code is not that clever. :-)

I figured out the sws.zip file problem and created a pull request for the notebook.

comment:54 in reply to: ↑ 53 Changed 7 years ago by kcrisman

I figured out the sws.zip file problem and created a pull request for the notebook.

You mean this pull request.

Changed 7 years ago by iandrus

comment:55 Changed 7 years ago by iandrus

  • Description modified (diff)

I found a problem where Sage.app could incorrectly determine if the server was running! I was assuming that a string had a final null byte, but that wasn't guaranteed. So depending on the contents of memory it would often work correctly but could fail. I think it works more often when debugging which is partly why I hadn't noticed it before. I have included it as a separate patch so there is less to review.

This should fix the problem of starting the server twice.

comment:56 follow-up: Changed 7 years ago by nkirchner

One way to get the server to start twice is as follows (with the extcode patch but no fix-parse-error patch and no sagenb fix for the .sws.zip business):

  1. Attempt to open a .sws.zip file from Finder.
  2. Quit Sage.app & all python2.7 processes.
  3. Attempt to open the same .sws.zip file.

Applying the fix-parse-error patch indeed fixes the issue; the server starts only once and pulls up the "Error opening the worksheet" page after step 3.

With the extcode patch and the fix-parse-error patch, Sage.app:

  • starts and stops the server properly,
  • handles .txt, .txt.zip, and .sws files properly when they are opened from Finder,
  • hasn't started the server twice in my testing.

comment:57 in reply to: ↑ 56 Changed 7 years ago by iandrus

Replying to nkirchner:

With the extcode patch and the fix-parse-error patch, Sage.app:

  • starts and stops the server properly,
  • handles .txt, .txt.zip, and .sws files properly when they are opened from Finder,
  • hasn't started the server twice in my testing.

Yippee!

comment:58 Changed 7 years ago by iandrus

  • Status changed from needs_info to needs_review

What still needs to be done for this to get a positive review. I appreciate everything you guys have done and I think this is ready to go in soon. If there is anything I can do to help, let me know.

comment:59 Changed 7 years ago by kcrisman

I want to try it on OS X 10.4. Someone should try it on Mountain Lion. That's it.

comment:60 Changed 7 years ago by nkirchner

You should consider me to have given a positive review for 10.7. I'm deferring to kcrisman the "official" status change.

comment:61 Changed 7 years ago by kcrisman

  • Description modified (diff)

comment:62 Changed 7 years ago by kcrisman

See also #14044.

comment:63 Changed 7 years ago by kcrisman

  • Cc jhpalmieri added

My machine is so old and slow that this still causes problems. Double clicking does indeed work to start Sage (as it has for a while) but I have no fewer than three open tabs for it.

  • One asking to sign in, with a redirect to loading the worksheet (of course I have no idea what my login is! blanks, admin/sage, admin/admin all don't work)
  • One asking to sign in, with the "startup_token" thing for logging in, perhaps, but it didn't log in yet
  • One with a list of my active worksheets (!)

Once I am actually already started, it does upload as promised! I think maybe you can add something to the README for the Mac app that says "user beware" on very old systems with little RAM and/or 10.4/10.5 and/or PPC, and I would be satisfied.


I think we do need someone to make sure it at least bdists and starts correctly on 10.8. John, would you be willing to do the following?

  • Add these patches to the extcode repo (data/sage/ext, I think)
  • export SAGE_APP_BUNDLE=yes
  • ./sage -bdist Sage-testing-doubleclick
  • Wait
  • Move the bdist app somewhere and use it to double click an sws file

We just need to make sure this doesn't break something horribly.

comment:64 Changed 7 years ago by jhpalmieri

When I run ./sage -bdist Sage-testing-doubleclick, I get an error:

Copying Sage.app
sed: RE error: illegal byte sequence
Creating sage-Sage-testing-doubleclick-x86_64-Darwin.dmg

Anyone else see this? It more or less seems to work, except that I see

	<string>Sage-testing-doubleclick^S</string>

in Info.plist: note that extra character after "doubleclick". It seems to work anyway...

As far as double-clicking, I already have this. Maybe I told the OS to use the Sage app to always open sws files before?

But nothing seems to be horribly broken.

comment:65 Changed 7 years ago by kcrisman

Ivan, is this easy to fix (the sed thing)? Maybe that extra character is indeed the problem.

John, can you upload that bdist someplace convenient? I have someone next to me at the Sage Days at ICERM who could probably test it right now and then we might be able to do a positive review, modulo that extra character or whatever.

comment:66 Changed 7 years ago by kcrisman

I do get the following warning on 10.7.

/Users/.../sage-5.7.beta4/devel/ext-main/sage/ext/mac-app/AppDelegate.m:38:65: warning: format specifies type 'int' but the argument has type 'OSStatus' (aka 'long') [-Wformat]
            NSLog(@"Could not show Sage.app in the dock. Error %d", returnCode);
                                                               ~^   ~~~~~~~~~~
                                                               %ld

comment:67 follow-up: Changed 7 years ago by jhpalmieri

I see that warning plus a few others on 10.8:

/Users/.../sage-5.7.beta4/devel/ext-main/sage/ext/mac-app/AppController.m:413:52: warning: format specifies type 'unsigned short' but the argument has type 'int' [-Wformat]
                 [NSString stringWithFormat:@"%C", 0x2026]]]; // @"…"
                                              ~~   ^~~~~~
                                              %d
/Users/.../sage-5.7.beta4/devel/ext-main/sage/ext/mac-app/AppController.m:445:55: warning: format specifies type 'unsigned short' but the argument has type 'int' [-Wformat]
            sessionType ? sessionType : @"", command, 0x2026];
                                                      ^~~~~~
/Users/.../sage-5.7.beta4/devel/ext-main/sage/ext/mac-app/AppController.m:552:69: warning: format specifies type 'long' but the argument has type 'OSErr' (aka 'short') [-Wformat]
        NSLog(@"Unable to determine gestaltSystemVersionMajor: %ld",err);
                                                               ~~~  ^~~
                                                               %hd
/Users/.../sage-5.7.beta4/devel/ext-main/sage/ext/mac-app/AppController.m:557:69: warning: format specifies type 'long' but the argument has type 'OSErr' (aka 'short') [-Wformat]
        NSLog(@"Unable to determine gestaltSystemVersionMinor: %ld",err);
                                                               ~~~  ^~~
                                                               %hd
4 warnings generated.

Meanwhile, here is a bdist built on OS X 10.8, if anyone wants to test it.

comment:68 Changed 7 years ago by kcrisman

  • Reviewers changed from Karl-Dieter Crisman, Nicholas Kirchner to Karl-Dieter Crisman, Nicholas Kirchner, John Palmieri

I've opened a thread on sage-devel for this. Thanks! Hopefully we are truly within epsilon.

comment:69 Changed 7 years ago by jhpalmieri

The sed problem is with the file ./Sage.app/Contents/Resources/English.lproj/InfoPlist.strings. If I remove this from the sed command in sage-bdist, the error message goes away. On my system, while in the mac-app directory, after running sage-bdist:

$ file English.lproj/InfoPlist.strings 
English.lproj/InfoPlist.strings: ASCII c program text
$ file build/Debug/Sage.app/Contents/Resources/English.lproj/InfoPlist.strings 
build/Debug/Sage.app/Contents/Resources/English.lproj/InfoPlist.strings: Little-endian UTF-16 Unicode c program text

That last part looks suspicious to me. Indeed, if I run sed on the first file, it works fine, but if I run it on the second, I get "sed: RE error: illegal byte sequence". How hard is it to fix this?

comment:70 in reply to: ↑ 67 Changed 7 years ago by iandrus

Replying to jhpalmieri:

I see that warning plus a few others on 10.8:

/Users/.../sage-5.7.beta4/devel/ext-main/sage/ext/mac-app/AppController.m:413:52: warning: format specifies type 'unsigned short' but the argument has type 'int' [-Wformat]
                 [NSString stringWithFormat:@"%C", 0x2026]]]; // @"…"
                                              ~~   ^~~~~~
                                              %d
/Users/.../sage-5.7.beta4/devel/ext-main/sage/ext/mac-app/AppController.m:445:55: warning: format specifies type 'unsigned short' but the argument has type 'int' [-Wformat]
            sessionType ? sessionType : @"", command, 0x2026];
                                                      ^~~~~~
/Users/.../sage-5.7.beta4/devel/ext-main/sage/ext/mac-app/AppController.m:552:69: warning: format specifies type 'long' but the argument has type 'OSErr' (aka 'short') [-Wformat]
        NSLog(@"Unable to determine gestaltSystemVersionMajor: %ld",err);
                                                               ~~~  ^~~
                                                               %hd
/Users/.../sage-5.7.beta4/devel/ext-main/sage/ext/mac-app/AppController.m:557:69: warning: format specifies type 'long' but the argument has type 'OSErr' (aka 'short') [-Wformat]
        NSLog(@"Unable to determine gestaltSystemVersionMinor: %ld",err);
                                                               ~~~  ^~~
                                                               %hd
4 warnings generated.

These warnings (and the one noted by kcrisman) should be harmless.

Meanwhile, here is a bdist built on OS X 10.8, if anyone wants to test it.

Awesome, thanks.

Replying to jhpalmieri:

The sed problem is with the file ./Sage.app/Contents/Resources/English.lproj/InfoPlist.strings. If I remove this from the sed command in sage-bdist, the error message goes away. On my system, while in the mac-app directory, after running sage-bdist:

$ file English.lproj/InfoPlist.strings 
English.lproj/InfoPlist.strings: ASCII c program text
$ file build/Debug/Sage.app/Contents/Resources/English.lproj/InfoPlist.strings 
build/Debug/Sage.app/Contents/Resources/English.lproj/InfoPlist.strings: Little-endian UTF-16 Unicode c program text

That last part looks suspicious to me. Indeed, if I run sed on the first file, it works fine, but if I run it on the second, I get "sed: RE error: illegal byte sequence". How hard is it to fix this?

We can remove this. The file is for localizing some of the strings, but we don't do that anyway. It used to be that it was an xml plist file, but I guess they changed it to be a binary plist file in order to save space. The ^S is an unrelated problem.

I'm adding a patch fixing the warnings and removing the ^S.

Changed 7 years ago by iandrus

Changed 7 years ago by iandrus

comment:71 Changed 7 years ago by kcrisman

Well, patches apply, anyway. John, can you test on yours? I'm testing that this removes the warnings on mine.

comment:72 follow-up: Changed 7 years ago by iandrus

Replying to jhpalmieri:

As far as double-clicking, I already have this. Maybe I told the OS to use the Sage app to always open sws files before?

Um. What exactly does it do? Until recently there wasn't a way to upload the sws file to the notebook server. Well, at least not easily. So I would be surprised if it worked "correctly" for you, namely, creating a new worksheet from the sws file. Double clicking other types of files has worked for a long time.

comment:73 Changed 7 years ago by iandrus

  • Description modified (diff)

comment:75 in reply to: ↑ 72 Changed 7 years ago by jhpalmieri

Replying to iandrus:

Replying to jhpalmieri:

As far as double-clicking, I already have this. Maybe I told the OS to use the Sage app to always open sws files before?

Um. What exactly does it do?

Oh, you're right. The file already had the correct icon, and when I double-clicked on it, the Sage app opened, but then it gave me an error message about some other ticket (which was closed as a duplicate of this one).

With the patches applied, it seems to work right.

comment:76 Changed 7 years ago by kcrisman

  • Status changed from needs_review to positive_review

According to this sage-devel thread, success on 10.8!

And no problems for me either on 10.7. Let's get this in!

comment:77 Changed 7 years ago by jdemeyer

  • Milestone changed from sage-5.7 to sage-5.8

comment:78 Changed 7 years ago by jdemeyer

  • Merged in set to sage-5.8.beta0
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.