A Mac OS X Sage Launcher
adam
It is easy to create an AppleScript applet that will launch "sage".
Assuming the sage
folder is within the Mac OS X Applications folder, the script is
tell application "Terminal"
do script "/Applications/sage/sage"
end tell
This script can be saved as a double-clickable application with its
own icon.
Let me know if you would like a copy of the version I created with an
icon
based on the sage logo.
Adam
mabshoff
On Dec 24, 1:18 pm, adam <ahauskne...@umassd.edu> wrote:
> Hi all,
Hi Adam,
similar that can handle moving Sage around gracefully.
> Adam
Cheers,
Michael
Ray Kiddy
I was looking at this and the explanation in the bug seems a little
complicated.
One can create a project (of almost any kind) in Xcode and build it. I
called mine "sage" and got a "sage.app" from the build. Delete the
Resources directory. Take a /bin/sh script that calls "open -f
Terminal.app $location/sage" and move it to sage.app/Contents/MacOS/
sage.
This turns "sage.app" into a double-clickable app that launches sage
and shuts down.
The icon is just gravy.
- ray
kcrisman
> I was looking at this and the explanation in the bug seems a little
> complicated.
kind of thing, I just cobbled together hints from a wide variety of
sources and people to get something that worked and actually was an
app, not just a script.
>
> One can create a project (of almost any kind) in Xcode and build it. I
everything including .plist by hand. Certainly if this would make
things more streamlined it would be great; up to now (many months) no
one has given instructions for this.
> called mine "sage" and got a "sage.app" from the build. Delete the
> Resources directory. Take a /bin/sh script that calls "open -f
> Terminal.app $location/sage" and move it to sage.app/Contents/MacOS/
> sage.
>
> This turns "sage.app" into a double-clickable app that launches sage
> and shuts down.
implementing #4817 does as well, except without the $location trick,
which no one has ever told us about before.
> The icon is just gravy.
users. Does that have to be removed? It would be a shame to have a
shorter script that for some reason didn't allow that.
Anyway, it sounds like the long-sought OSX gurus (see the OSX readme
file) are finally arriving on the list the last few months! Thanks,
and anything that makes this more efficient (e.g. not creating random /
tmp/ files) will be a great addition to Sage.
- kcrisman
PS: The final step in the whole saga would be to use Interface Builder
to make, well, an interface (which presumably would just add some kind
of Aqua niceness to a terminal session implanted in the interface?).
I have no idea how to do this, but http://www.iwu.edu/~cskiadas/Apps/index.html
is an older example of doing this with Macaulay 2 which as far as I
know was fairly functional. Anyway, that would be suh-weet.
Ivan Andrus
> to make, well, an interface (which presumably would just add some kind
> of Aqua niceness to a terminal session implanted in the interface?).
> I have no idea how to do this, but http://www.iwu.edu/~cskiadas/Apps/index.html
> is an older example of doing this with Macaulay 2 which as far as I
> know was fairly functional. Anyway, that would be suh-weet.
I don't know if we could make Platypus <http://www.sveinbjorn.org/platypus
> part of the build process, but it's very nice and can easily
integrate into a command-line build process. It creates the bundle
and everything for you. It's GPL, if it helps. I would have
suggested this a lot sooner, but just starting the sage server isn't
that exciting to me. What I want is a dedicated application (like the
Macaulay front end), but one that opens a browser window instead of a
terminal.
What I use is a hacked up version of a Site Specific Browser created
with Fluid <http://fluidapp.com/> that starts the server in the
background and opens a browser window. Unfortunately, Fluid is closed
source, but something like Prism might work. It's been a while since
I looked at Prism, so it might suck less now. I could never even
figure out how to begin to build it (and the forums were no help
despite several people asking the same question--Argh!). Anyway, if I
have some time (not likely in the near future) I will look into a
Prism application, or creating an SSB from scratch to use with sage.
It really shouldn't be that hard, but my Cocoa skills aren't that
great. Either that or I might try and add browser windows to Platypus.
-Ivan
kcrisman
Ivan:
http://groups.google.com/group/sage-devel/browse_thread/thread/86b087a2fb157678
http://groups.google.com/group/sage-devel/browse_thread/thread/647f9610f161f2fd
http://groups.google.com/group/sage-devel/browse_thread/thread/a6b8dced9953074e
http://groups.google.com/group/sage-devel/browse_thread/thread/c181f8ccde549cdd
I have been spectacularly unsuccessful with Platypus, but it certainly
sounds like others have been able to get it working.
Anyway, it sounds like what mabshoff really needs is just the best
tarball possible to then be able to drop a Sage build into for a fully
functional .app bundle. If that was created just once with Platypus
by someone else, presumably for every new Sage release the new binary
could just be dropped into the bundle.
My own bundle is very bare-bones - so for instance the suggestion
above about "open -f Terminal.app $location/sage" might make it
better. If someone sent mabshoff one that supported things like
knowing whether Terminal was already open, whether a Sage process was
already running, being able to drag-and-drop .sws or .py or .sage
files (contextually knowing whether to open the notebook!) that would
be even sweeter!
But it sounds like (correct me if I'm wrong) the thing which has held
this up lo these many months and threads is just having something that
could be fully automated, needing no additional effort other than
slapping a new binary in or perhaps changing a version number, which a
script could do.
- kcrisman
mabshoff
On Jan 30, 7:47 am, kcrisman <kcris...@gmail.com> wrote:
Hi,
> Platypus has been discussed a number of times before, including by
> Ivan:
>
> I have been spectacularly unsuccessful with Platypus, but it certainly
> sounds like others have been able to get it working.
> Anyway, it sounds like what mabshoff really needs is just the best
> tarball possible to then be able to drop a Sage build into for a fully
> functional .app bundle. If that was created just once with Platypus
> by someone else, presumably for every new Sage release the new binary
> could just be dropped into the bundle.
>
> My own bundle is very bare-bones - so for instance the suggestion
> above about "open -f Terminal.app $location/sage" might make it
> better. If someone sent mabshoff one that supported things like
> knowing whether Terminal was already open, whether a Sage process was
> already running, being able to drag-and-drop .sws or .py or .sage
> files (contextually knowing whether to open the notebook!) that would
> be even sweeter!
the best solution not in Sage by a mile :)
> But it sounds like (correct me if I'm wrong) the thing which has held
> this up lo these many months and threads is just having something that
> could be fully automated, needing no additional effort other than
> slapping a new binary in or perhaps changing a version number, which a
> script could do.
"sage -bdist" is worthless since it requires manual interaction. But
something that works better than we have and for now has to be run
manually should be used to make the integrated version better.
> - kcrisman
Cheers,
Michael
kcrisman
Two followups:
>
> Yep, and given that it isn't open source I would rather not touch it.
that isn't. But it still requires rather a lot of interaction for
someone not too familiar with scripting, enough that I was foiled when
I tried it in the past.
>
> To be overly dramatic: Anything not automated and integrated into
> "sage -bdist" is worthless since it requires manual interaction. But
> something that works better than we have and for now has to be run
> manually should be used to make the integrated version better.
closed soon? Maybe the bundle wasn't enough - but I can't help with
changing sage -bdist, whatever that is; I know nothing of such
things. Sorry!
- kcrisman
mabshoff
On Jan 30, 8:38 am, kcrisman <kcris...@gmail.com> wrote:
> Two followups:
>
>
>
> > Yep, and given that it isn't open source I would rather not touch it.
>
> 1. Platypus is GPL, as Ivan correctly points out above. It was Fluid
> that isn't. But it still requires rather a lot of interaction for
> someone not too familiar with scripting, enough that I was foiled when
> I tried it in the past.
likely see the solution you are providing unless someone else steps up
to the plate.
>
>
> > To be overly dramatic: Anything not automated and integrated into
> > "sage -bdist" is worthless since it requires manual interaction. But
> > something that works better than we have and for now has to be run
> > manually should be used to make the integrated version better.
>
> 2. So does your last comment mean that #4817 is or isn't going to be
> closed soon? Maybe the bundle wasn't enough - but I can't help with
> changing sage -bdist, whatever that is; I know nothing of such
> things. Sorry!
popped up and fixing that trumps anything else, but there is still a
good chance that I will work on this before the final 3.3 since I
consider it very important that the experience of Sage on OSX is as
smooth as possible. The remark on #4817 was the usual attempt to make
someone else do the work :)
> - kcrisman
Cheers,
Michael
Ivan Andrus
> Anyway, it sounds like what mabshoff really needs is just the best
> tarball possible to then be able to drop a Sage build into for a fully
> functional .app bundle. If that was created just once with Platypus
> by someone else, presumably for every new Sage release the new binary
> could just be dropped into the bundle.
Well, you have finally goaded me into doing something :-) I nearly
have a patch, and hopefully I'll post something to trac in the next
few days for review.
I do have one question though. What directory should I put the data
files in (the icon etc.)? My guess would be devel/sage-main/build/,
maybe in a new subdirectory, but I'm still not comfortable enough with
the directory structure to be sure.
-Ivan
P.S. Oops, I sent this from the wrong email address and it doesn't
look like it showed up.
mabshoff
On Feb 2, 11:23 pm, Ivan Andrus <g...@macmail.com> wrote:
> On Jan 30, 2009, at 8:47 AM, kcrisman wrote:
> > Anyway, it sounds like what mabshoff really needs is just the best
> > tarball possible to then be able to drop a Sage build into for a fully
> > functional .app bundle. If that was created just once with Platypus
> > by someone else, presumably for every new Sage release the new binary
> > could just be dropped into the bundle.
>
> Well, you have finally goaded me into doing something :-) I nearly
> have a patch, and hopefully I'll post something to trac in the next
> few days for review.
>
> I do have one question though. What directory should I put the data
> files in (the icon etc.)? My guess would be devel/sage-main/build/,
> maybe in a new subdirectory, but I'm still not comfortable enough with
> the directory structure to be sure.
not survive an -sdist.
The appropriate place at the moment would probably be in the ext repo,
but that repo will go away in the future. But we can deal with that
then since all the content from ext will migrate into some place under
devel modulo some bits that will end up in their own spkg.
The way I would do it is to stick all the needed bits into a tar.gz
and check that into the ext repo into some new directory like mac-app.
Then on -sdist a script would unpack that tar.gz, move the sage
install into the right place and then proceed with creating the dmg.
> -Ivan
>
> P.S. Oops, I sent this from the wrong email address and it doesn't
> look like it showed up.
Cheers,
Michael
mabshoff
in a couple hours will create a Sage app if you run -bdist. Check out
a screenshot of it in action at
http://sage.math.washington.edu/home/mabshoff/SageApp.png
It is based on Sage 3.3.alpha0 since I did no feel like hosing my
current alpha4 build, but it works very well. Note that a couple
things need to be fixed, but that will be done later. Another issue is
that we should create the app without having to run bdist since that
takes rather long. In the png you can see the console of the current
output from the notebook, the about Sage dialog and the icon. All in
all very smooth and certainly a giant improvement in usability if you
ask me.
So thanks to Karl-Dieter and Ivan for finally makeing this a reality
since we have been talking about this since ye old Sage 2.5 at least
when I posted some crummy manually assembled app.
Cheers,
Michael
kcrisman
> since we have been talking about this since ye old Sage 2.5 at least
> when I posted some crummy manually assembled app.
than anything I could cook up. I have to say that I prefer the
icosahedron icon, though :) And the hope is that now one could much
more easily make incremental improvements to this skeleton in order to
support e.g. dropping .sws or .sage files on it.
I look forward to using it!
- kcrisman
Ivan Andrus
It was the only icon I could find in the (admittedly short) time I
looked. Where could I get the icon (as large as possible)? Also, if
you can tell me what to do with dropped files I could easily add
that. i.e. how does one open a .sage file in the notebook from the
command line. I'm sure it's very simple, I just haven't looked at it
yet. Any other suggestions are welcome as well.
-Ivan
William Stein
Hmm... there might actually be no way to do that. Just to start
thinking about this, we would need:
(1) a special URL to go to, e.g.,
http://localhost:8000/open_file/absolute_path_to_file_on_local_filesystem.sage
and
(2) a command line option, e.g.,
$ sage foo.sws
would start a notebook server if it isn't already running, and once it
is, would call basically (1) above for the default sage notebook
server running from $DOT_SAGE/sage_notebook.
William
mabshoff
On Feb 3, 7:07 pm, William Stein <wst...@gmail.com> wrote:
<SNIP>
> > It was the only icon I could find in the (admittedly short) time I
> > looked. Where could I get the icon (as large as possible)? Also, if
> > you can tell me what to do with dropped files I could easily add
> > that. i.e. how does one open a .sage file in the notebook from the
> > command line. I'm sure it's very simple, I just haven't looked at it
> > yet. Any other suggestions are welcome as well.
>
> Hmm... there might actually be no way to do that. Just to start
> thinking about this, we would need:
>
> and
>
> (2) a command line option, e.g.,
>
> $ sage foo.sws
>
> would start a notebook server if it isn't already running, and once it
> is, would call basically (1) above for the default sage notebook
> server running from $DOT_SAGE/sage_notebook.
(a) dropping a sws into firefox and having Sage deal with the event
some way
(b) write something more full fledged on a CoCoA level and have that
deal with drag & drop events
Unfortunately I don't have the time, but some other people might have
written code in that direction already.
> William
Cheers,
Michael
William Stein
>
>
>
> On Feb 3, 7:07 pm, William Stein <wst...@gmail.com> wrote:
>
> <SNIP>
>
>> > It was the only icon I could find in the (admittedly short) time I
>> > looked. Where could I get the icon (as large as possible)? Also, if
>> > you can tell me what to do with dropped files I could easily add
>> > that. i.e. how does one open a .sage file in the notebook from the
>> > command line. I'm sure it's very simple, I just haven't looked at it
>> > yet. Any other suggestions are welcome as well.
>>
>> Hmm... there might actually be no way to do that. Just to start
>> thinking about this, we would need:
>>
>> (1) a special URL to go to, e.g.,http://localhost:8000/open_file/absolute_path_to_file_on_local_filesy...
>>
>> and
>>
>> (2) a command line option, e.g.,
>>
>> $ sage foo.sws
>>
>> would start a notebook server if it isn't already running, and once it
>> is, would call basically (1) above for the default sage notebook
>> server running from $DOT_SAGE/sage_notebook.
>
> I am not sure that will work too well.
saying it will be easy to do -- it would likely take several hours
work -- but I don't see any technical problem with doing it. I'm
sure somebody like Mike Hansen who knows the notebook code would
agree. I would do the above by adding something to
.sage/sage_notebook that has the port of the currently running sage
notebook server (if one is running), then at a Resource in
sage/server/notebook/twist.py that handles uploading an sws (there is
already one, probably). Then add a command line option to
sage/local/bin/sage-sage for handling sws files.
> I can see two things:
>
> (a) dropping a sws into firefox and having Sage deal with the event
> some way
>
> (b) write something more full fledged on a CoCoA level and have that
> deal with drag & drop events
>
> Unfortunately I don't have the time, but some other people might have
> written code in that direction already.
>
>> William
>
> Cheers,
>
> Michael
> >
>
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
mabshoff
On Feb 3, 7:16 pm, William Stein <wst...@gmail.com> wrote:
> >> would start a notebook server if it isn't already running, and once it
> >> is, would call basically (1) above for the default sage notebook
> >> server running from $DOT_SAGE/sage_notebook.
>
> > I am not sure that will work too well.
>
> Why not? I can easily see how to implement (1) and (2). I'm not
> saying it will be easy to do -- it would likely take several hours
> work -- but I don't see any technical problem with doing it. I'm
> sure somebody like Mike Hansen who knows the notebook code would
> agree. I would do the above by adding something to
> .sage/sage_notebook that has the port of the currently running sage
> notebook server (if one is running), then at a Resource in
> sage/server/notebook/twist.py that handles uploading an sws (there is
> already one, probably). Then add a command line option to
> sage/local/bin/sage-sage for handling sws files.
>
what you suggest is as you said doable with a couple hours work.
I also misspelled Cocoa - I guess it is that old habits die hard.
Cheers,
Michael
kcrisman
> It was the only icon I could find in the (admittedly short) time I
> looked. Where could I get the icon (as large as possible)?
front page of this google group. It's not particularly big,
unfortunately.
- kcrisman
kcrisman
> >> more easily make incremental improvements to this skeleton in order to
> >> support e.g. dropping .sws or .sage files on it.
support that on the command line level at least.
- kcrisman
Dan Drake
> You're welcome, and thanks to Ivan as well, as this seems to be nicer
> than anything I could cook up. I have to say that I prefer the
> icosahedron icon, though :)
I happen to prefer the orange perspective-cube. Just sayin'...
> And the hope is that now one could much
> more easily make incremental improvements to this skeleton in order to
> support e.g. dropping .sws or .sage files on it.
This sounds like a great idea. I've always liked that in OS X if you
drop a file on a program's icon, it does the obvious thing with it. I'm
sure we can get somethign working.
This is very nice work! I will install this on my Macbook as soon as I
can.
Dan
--
--- Dan Drake <dr...@kaist.edu>
----- KAIST Department of Mathematical Sciences
------- http://mathsci.kaist.ac.kr/~drake
Martin Albrecht
+1
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de
Martin Albrecht
> thinking about this, we would need:
>
> (1) a special URL to go to, e.g.,
> http://localhost:8000/open_file/absolute_path_to_file_on_local_filesystem.s
>age
This would open the file dialog in my browser, right? AFAIK websites can't
just open local files and they shouldn't:
"""
Dear Sage user,
just click on this link to see a proof of the Riemann hypothesis done in Sage:
http://localhost:8000/open_file/etc/passwd
"""
Cheers,
William Stein
<ma...@informatik.uni-bremen.de> wrote:
>
>> Hmm... there might actually be no way to do that. Just to start
>> thinking about this, we would need:
>>
>> (1) a special URL to go to, e.g.,
>> http://localhost:8000/open_file/absolute_path_to_file_on_local_filesystem.s
>>age
>
> This would open the file dialog in my browser, right?
Yes.
> AFAIK websites can't
> just open local files and they shouldn't:
Since this is localhost this is trivial to do. I don't understand why
you think it wouldn't be????
>
> """
> Dear Sage user,
>
> just click on this link to see a proof of the Riemann hypothesis done in Sage:
>
> http://localhost:8000/open_file/etc/passwd
> """
So? You could also type
os.system('cat /etc/passwd')
in any notebook cell and cell exactly the same thing.
-- William
Martin Albrecht
> > Dear Sage user,
> >
> > just click on this link to see a proof of the Riemann hypothesis done in
> > Sage:
> >
> > http://localhost:8000/open_file/etc/passwd
> > """
>
> So? You could also type
Sorry, I meant to put some URL that is not localhost.
> os.system('cat /etc/passwd')
>
> in any notebook cell and cell exactly the same thing.
Yeah sure, if we're talking localhost only than everything is almost trivial.
However, the issue still is who's right to open the file are we invoking? The
user's (by letting the browser deal with the file reading/sending or the
server's (by calling open("/etc/passwd")). I think it should be the user's
since the server should not be able to read a user's $HOME if not run by the
user.
Bottomline: everything goes through the browser's file upload dialog anyway
and thus we don't have to worry about security implications.
William Stein
<ma...@informatik.uni-bremen.de> wrote:
>
>> > """
>> > Dear Sage user,
>> >
>> > just click on this link to see a proof of the Riemann hypothesis done in
>> > Sage:
>> >
>> > http://localhost:8000/open_file/etc/passwd
>> > """
>>
>> So? You could also type
>
> Sorry, I meant to put some URL that is not localhost.
>
>> os.system('cat /etc/passwd')
>>
>> in any notebook cell and cell exactly the same thing.
>
> Yeah sure, if we're talking localhost only than everything is almost trivial.
discussion was for Sage for local OS X GUI users, who want to be able
to double click on a .sws file and see the sage notebook open that
file and display it.
> However, the issue still is who's right to open the file are we invoking? The
> user's (by letting the browser deal with the file reading/sending or the
> server's (by calling open("/etc/passwd")). I think it should be the user's
> since the server should not be able to read a user's $HOME if not run by the
> user.
>
> Bottomline: everything goes through the browser's file upload dialog anyway
> and thus we don't have to worry about security implications.
the upload dialog. The server could just read the file off the
filesystem.
Thanks for pointing out the distinction, which could really matter for
implementing this, though it won't matter for this particular scenario
(OS X gui users).
>
> Martin
>
>
> --
> name: Martin Albrecht
> _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
> _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
> _www: http://www.informatik.uni-bremen.de/~malb
> _jab: martinr...@jabber.ccc.de
>
>
> >
>
Martin Albrecht
> > anyway and thus we don't have to worry about security implications.
>
> Actually, since this is local there is no need for it to go through
> the upload dialog. The server could just read the file off the
> filesystem.
>
> Thanks for pointing out the distinction, which could really matter for
> implementing this, though it won't matter for this particular scenario
> (OS X gui users).
So there would be a flag like SAGE_IMREALLYREALLYLOCAL which indicates that
the user who's using Sage is in fact the same person who started it? We don't
want to trigger reading files and such as a response to a simple HTTP GET
(think phishing and stuff) for server's which are not 100% local use only.
William Stein
<ma...@informatik.uni-bremen.de> wrote:
>
>> > Bottomline: everything goes through the browser's file upload dialog
>> > anyway and thus we don't have to worry about security implications.
>>
>> Actually, since this is local there is no need for it to go through
>> the upload dialog. The server could just read the file off the
>> filesystem.
>>
>> Thanks for pointing out the distinction, which could really matter for
>> implementing this, though it won't matter for this particular scenario
>> (OS X gui users).
>
>
> So there would be a flag like SAGE_IMREALLYREALLYLOCAL which indicates that
> the user who's using Sage is in fact the same person who started it? We don't
> want to trigger reading files and such as a response to a simple HTTP GET
> (think phishing and stuff) for server's which are not 100% local use only.
Well we could not have the option at all if the server isn't only
serving on localhost.
Thanks for pointing out this security implication.
William