Options

An Azimuth web server

I have set up a web server with shell access as a prototype testbed for azimuth server-side applications written for pretty much whatever x86_64 compiler anybody might want.

  • the installed compilers are gcc, g++, javac, ghc-7.4.1, gfortran.
  • the installed interpreters are cgi, php, perl, python, lua.
  • the usual javascript libraries, too numerous to mention are also installed

The processor is a 2.4GHz Intel quad-core with, if I've read /proc/meminfo correctly, 33007576 kB = 4.125 GB (kB = kilobit not kilobyte).

Haskell scientific "multicore fp is the only future" fans like me might wish to try and implement some Repa, Paraiso or Ypnos applications :)

Applications accompanied by a GUI interface specification in css3, html5 or javascript are welcome!

There is currently only a login screen on the server.

«1

Comments

  • 1.
    edited July 2012

    The link to your site does not work.

    The gcc C++ compiler is called g++, not gcc++.

    The gcc Fortran compiler conforms to the Fortran 95 standard. Does fortran90 exist?

    CGI is not an interpreter, it is an interface to allow a web server to call server-side scripts and executables on request from the browser.

    You do not say that it is a Haskell-based Snap server, rather than, say, Apache.

    Comment Source:The link to your site does not work. The gcc C++ compiler is called g++, not gcc++. The gcc Fortran compiler conforms to the Fortran 95 standard. Does fortran90 exist? CGI is not an interpreter, it is an interface to allow a web server to call server-side scripts and executables on request from the browser. You do not say that it is a Haskell-based [Snap](http://snapframework.com/) server, rather than, say, Apache.
  • 2.
    edited August 2012

    Rebooted and corrected. Deleted cgi as it's only a possibility if, say someone writes something in perl. I'll try and avoid it.FWIW I was punning on cgi as an interpreter for html request strings :) Fortran 90 is used by GFDL. To reboot the snap server instance above go to public_html/bin/azimuth and type:

    nohup ./bin/azimuth  -p8000 &
    

    I thought the problem was I missed off the & but I'd stupidly put nohup in the wrong place on the server and here. Tnx

    Comment Source:Rebooted and corrected. Deleted cgi as it's only a possibility if, say someone writes something in perl. I'll try and avoid it.FWIW I was punning on cgi as an interpreter for html request strings :) Fortran 90 is used by [GFDL](http://vis.lbl.gov/~romano/climate/tropicalstorms.html#compiling). To reboot the [snap server](http:snapframework.com) instance above go to public_html/bin/azimuth and type: nohup ./bin/azimuth -p8000 & I thought the problem was I missed off the & but I'd stupidly put nohup in the wrong place on the server and here. Tnx
  • 3.

    Jim wrote:

    I have set up a web server with shell access as a prototype testbed for azimuth server-side applications written for pretty much whatever x86_64 compiler anybody might want.

    Cool, great! What do you envision wanting to do with this? I'm computer illiterate compared to most of you guys, so explain it nice and simple.

    Comment Source:Jim wrote: > I have set up a web server with shell access as a prototype testbed for azimuth server-side applications written for pretty much whatever x86_64 compiler anybody might want. Cool, great! What do you envision wanting to do with this? I'm computer illiterate compared to most of you guys, so explain it nice and simple.
  • 4.
    edited August 2012

    John, what Jim and I are intending is to provide an infrastructure for web-interactive climate models, where the heavy numeric computing is performed efficiently on a dedicated server, with Javascript running in the browser used for user input and graphics display. I outlined the options for web-interactive graphs in the For Übernerds Only section of the stochastic resonance blog. I got away with implementing the stochastic resonance interactive model entirely in Javascript, but more compute-intensive models would not I think be feasible with this approach.

    Jim and I now need to work on how executable code provided by Azimuth contributors can be installed on the server, and how this code is called from the web server.

    Comment Source:John, what Jim and I are intending is to provide an infrastructure for web-interactive climate models, where the heavy numeric computing is performed efficiently on a dedicated server, with Javascript running in the browser used for user input and graphics display. I outlined the options for web-interactive graphs in the For Übernerds Only section of the [stochastic resonance blog](http://johncarlosbaez.wordpress.com/2012/07/30/increasing-the-signal-to-noise-ratio-with-more-noise/). I got away with implementing the stochastic resonance interactive model entirely in Javascript, but more compute-intensive models would not I think be feasible with this approach. Jim and I now need to work on how executable code provided by Azimuth contributors can be installed on the server, and how this code is called from the web server.
  • 5.

    Great! I love working with people who can do things that are utterly beyond my capabilities!

    At some point I want to get a blog set up that allows these web applications to be run in blog articles. I don't like making people click a link to leave the blog to see the models you guys are making - I think it reduces the number of viewers and the overall coolness of it all.

    I like how Wordpress has lots of features; what I don't like are these aspects:

    1) skinny-column format

    2) no mathjax for TeX equations - so the equations look ugly

    3) using $latex instead of $ to begin math mode in TeX, which makes it harder to port the TeX from other formats (especially due to some other features that make a simple 'replace' not work so easily)

    4) not being able to include programs in the blog entries - or more precisely, not knowing how

    5) readers not being able to preview their comments

    I know that a bunch of these things could be fixed if I paid Wordpress to have my own blog on the UCR website (or somewhere), and perhaps they could all be fixed. I've been reluctant, not because of the money but because of the nuisance. I'm thinking it's time to look into this, and also other options.

    Comment Source:Great! I love working with people who can do things that are utterly beyond my capabilities! At some point I want to get a blog set up that allows these web applications to be run _in blog articles_. I don't like making people click a link to leave the blog to see the models you guys are making - I think it reduces the number of viewers and the overall coolness of it all. I like how Wordpress has lots of features; what I don't like are these aspects: 1) skinny-column format 2) no mathjax for TeX equations - so the equations look ugly 3) using $latex instead of $ to begin math mode in TeX, which makes it harder to port the TeX from other formats (especially due to some other features that make a simple 'replace' not work so easily) 4) not being able to include programs in the blog entries - or more precisely, not knowing how 5) readers not being able to preview their comments I know that a bunch of these things could be fixed if I paid Wordpress to have my own blog on the UCR website (or somewhere), and perhaps they could _all_ be fixed. I've been reluctant, not because of the money but because of the nuisance. I'm thinking it's time to look into this, and also other options.
  • 6.

    You don't need to pay Wordpress, just download their code and run it on a machine you have access to. You only need to pay (as far as I know) if you want more functionality but on their servers.

    Alternatively, you could make a segment of this place into a blog. It's already set up for it, you just have to make use of it. Then if there's anything you want to do that isn't already implemented - I don't know about embedding programs, for example - you know who to bug to get it done.

    Comment Source:You don't need to *pay* Wordpress, just download their code and run it on a machine you have access to. You only need to pay (as far as I know) if you want more functionality but on *their* servers. Alternatively, you could make a segment of this place into a blog. It's already set up for it, you just have to make use of it. Then if there's anything you want to do that isn't already implemented - I don't know about embedding programs, for example - you know who to bug to get it done.
  • 7.
    edited August 2012

    I was reluctant to disparage wordpress further - if it ain't broke don't fix it. I noticed that wordpress has lots of themes and they appear to be full screen width so I think that could be corrected.

    I intend to install various wiki and blogging softwares on this box. This will include gitit wiki software. John Mcfarlane is a great programmer (pandoc etc) and also a philosophy professor at Berkeley. Look in the tools directory of his site. He is very approachable.

    There is the excellent java software XWiki written in large part by Ludovic Dubost who worked for Netscape and on the png format. This is being used by various EU technical organisations and has a school education resource spinoff called curriki.

    I think blog software can be made out of almost any wiki software.

    Comment Source:I was reluctant to disparage wordpress further - if it ain't broke don't fix it. I noticed that wordpress has lots of themes and they appear to be full screen width so I think that could be corrected. I intend to install various wiki and blogging softwares on this box. This will include [gitit](http://johnmacfarlane.net) wiki software. John Mcfarlane is a great programmer (pandoc etc) and also a philosophy professor at Berkeley. Look in the tools directory of his site. He is very approachable. There is the excellent java software [XWiki](http://xwiki.org) written in large part by Ludovic Dubost who worked for Netscape and on the png format. This is being used by various EU technical organisations and has a school education resource spinoff called [curriki](http://www.curriki.org). I think blog software can be made out of almost any wiki software.
  • 8.

    I have installed:

    • llvm/clang - the high performance native C compiler for x86_64
    • openmpi the C, C++, Fortran 77 and Fortran 90 parallel processing library. I will try and install the missing Fortran compilers on demand. Fortran 95 is already installed.
    Comment Source:I have installed: * [llvm/clang](llvm.org) - the high performance native C compiler for x86_64 * [openmpi](open-mpi.org) the C, C++, Fortran 77 and Fortran 90 parallel processing library. I will try and install the missing Fortran compilers on demand. Fortran 95 is already installed.
  • 9.
    edited August 2012

    Jim, I think what we require is that the server interfaces to numeric processing code using fastcgi. This makes the interface language-independent. In particular, no Haskell FFI code is required. The advantages of using fastcgi are described in this white paper.

    For web-interactive computing, fastcgi offers the following advantages over using conventional CGI, or the Haskell FFI:

    1. The numeric computation application is launched once per session, and multiple requests (e.g. slider adjustments) are then processed efficiently. With conventional CGI, each request causes a new application process to be launched, which for slider adjustments could be on the order of a hundred times a second, so adding an enormous overhead.

    2. The numeric computation application is run as a separate process, rather than in the web server's address space, so preventing the application from crashing the server, or interfering with its operation. An application written in C/C++, and interfaced to the Snap server via the Haskell FFI, would run in the web server's address space, and thus expose the server to things like memory errors and exceptions.

    3. Contributors do not have to understand Haskell, or understand the Snap server framework, which they would if the Haskell FFI were used. Applications designed to work with the fastcgi protocol would work just as well with an Apache httpd server with mod_fastcgi installed.

    4. The Haskell FFI is primarily a C interface, which will not work directly with code written in languages like Python and Java. The fastcgi protocol will work with a great many languages, and I understand that it is not particularly difficult to implement fastcgi in any language, using the C SDK and the language's FFI.

    The question now is whether there is a Haskell implementation of the server-side of the fastcgi protocol, which can be plugged into the Snap framework. A client-side Haskell implementation would be good as well, so all code contributions work in the same way, regardless of the language they are implemented in.

    PS. I came across fastcgi because the Julia language uses it for web-interactive sessions.

    Comment Source:Jim, I think what we require is that the server interfaces to numeric processing code using [fastcgi](http://www.fastcgi.com/drupal/). This makes the interface language-independent. In particular, no Haskell FFI code is required. The advantages of using fastcgi are described in [this white paper](http://www.fastcgi.com/drupal/node/6?q=node/15). For web-interactive computing, fastcgi offers the following advantages over using conventional CGI, or the Haskell FFI: 1. The numeric computation application is launched once per session, and multiple requests (e.g. slider adjustments) are then processed efficiently. With conventional CGI, each request causes a new application process to be launched, which for slider adjustments could be on the order of a hundred times a second, so adding an enormous overhead. 1. The numeric computation application is run as a separate process, rather than in the web server's address space, so preventing the application from crashing the server, or interfering with its operation. An application written in C/C++, and interfaced to the Snap server via the Haskell FFI, would run in the web server's address space, and thus expose the server to things like memory errors and exceptions. 1. Contributors do not have to understand Haskell, or understand the Snap server framework, which they would if the Haskell FFI were used. Applications designed to work with the fastcgi protocol would work just as well with an Apache httpd server with mod_fastcgi installed. 1. The Haskell FFI is primarily a C interface, which will not work directly with code written in languages like Python and Java. The fastcgi protocol will work with [a great many languages](http://www.fastcgi.com/drupal/node/5), and I understand that it is not particularly difficult to implement fastcgi in any language, using the C SDK and the language's FFI. The question now is whether there is a Haskell implementation of the server-side of the fastcgi protocol, which can be plugged into the Snap framework. A client-side Haskell implementation would be good as well, so all code contributions work in the same way, regardless of the language they are implemented in. PS. I came across fastcgi because the Julia language uses it for web-interactive sessions.
  • 10.
    edited August 2012

    Have started some notes on some of the ideas you've raised. I short here's about where I've got to.

    I have no need to use cgi. If it was necessary you can use the Haskell fastcgi library from hackage and use ghc -c -fpic and link to create a main.cgi binary.

    I've chosen to use the hacked Texas Burgers Fortran code I've got as the proof of concept for a language other than Haskell or C.

    Sgiborne Fynn showed how to do this without going through C here

    the basic ABI is identical to that of C (gcc), since g77 shares the same backend.

    Here's the simple example I tested it with:
    
    foo$ cat square.f
      SUBROUTINE SQUARE(N,M)
      C     COMPUTES THE SQUARE OF N, RETURNS IN M
      M=N*N
      RETURN
     END
    C
    
    foo$ cat main.hs
    module Main where
    
    import Ptr
    import Storable
    import MarshalUtils
    import MarshalAlloc
    
    foreign import "square_" unsafe square_ :: Ptr Int -> Ptr Int -> IO Int
    
     square :: Int -> IO Int
     square x =
      withObject x $ \ ptr_x   ->
       alloca       $ \ ptr_res -> do
       square_ ptr_x ptr_res
       peek ptr_res
    
    main = square 11 >>= print
    

    {- --------------------- -}

    foo$ g77 -c square.f
    foo$ ghc -o main main.hs square.o -fglasgow-exts -package lang
    
    To get the name mangling and the details of passing arguments to the Fortran
    subroutine right, I looked at the output of "f2c -P", which gives back C
    prototypes for Fortran function/subs.
    

    You could certainly imagine a tool that would automate all this..

    hth
    --sigbjorn
    
    Comment Source:Have started some notes on some of the ideas you've raised. I short here's about where I've got to. I have no need to use cgi. If it was necessary you can use the Haskell fastcgi library from hackage and use ghc -c -fpic and link to create a main.cgi binary. I've chosen to use the hacked Texas Burgers Fortran code I've got as the proof of concept for a language other than Haskell or C. [Sgiborne Fynn showed how to do this without going through C here](http://www.haskell.org/pipermail/glasgow-haskell-users/2001-December/001249.html) > the basic ABI is identical to that of C (gcc), since g77 shares the same backend. > Here's the simple example I tested it with: > foo$ cat square.f > SUBROUTINE SQUARE(N,M) > C COMPUTES THE SQUARE OF N, RETURNS IN M > M=N*N > RETURN > END > C > foo$ cat main.hs > module Main where > import Ptr > import Storable > import MarshalUtils > import MarshalAlloc > foreign import "square_" unsafe square_ :: Ptr Int -> Ptr Int -> IO Int > square :: Int -> IO Int > square x = > withObject x $ \ ptr_x -> > alloca $ \ ptr_res -> do > square_ ptr_x ptr_res > peek ptr_res > main = square 11 >>= print > {- --------------------- -} > foo$ g77 -c square.f > foo$ ghc -o main main.hs square.o -fglasgow-exts -package lang > To get the name mangling and the details of passing arguments to the Fortran > subroutine right, I looked at the output of "f2c -P", which gives back C > prototypes for Fortran function/subs. > You could certainly imagine a tool that would automate all this.. > hth > --sigbjorn
  • 11.
    edited August 2012

    I haven't installed hmatrix yet, which provides an interface to BLAS and LAPACK which can be called from a Snaplet.

    The server has yum in /usr/include but tech support says they won't support it . I haven't installed BLAS, LAPACK and ATLAS yet. I seem to have half-installed rpmforge which appears to be recommended for installing these rpm packages on RHEL/Centos.

    The syntax for installing rpms in user space is:

    rpm2cpio whatever.rpm | cpio -ivd

    I'll bet you know more about redhat than I do. Anyway you might want to give it a try.

    Comment Source:I haven't installed hmatrix yet, which provides an interface to BLAS and LAPACK which can be called from a Snaplet. The server has yum in /usr/include but tech support says they won't support it . I haven't installed BLAS, LAPACK and ATLAS yet. I seem to have half-installed rpmforge which appears to be recommended for installing these rpm packages on RHEL/Centos. The syntax for installing rpms in user space is: > rpm2cpio whatever.rpm | cpio -ivd I'll bet you know more about redhat than I do. Anyway you might want to give it a try.
  • 12.
    edited August 2012

    Neil Michell has shown how to call Haskell from another language, in this case R, using a simple C stub.

    Calling Haskell from R

    C stub to be called from R and invoke Haskell.

    // StartEnd.c

    #include <Rts.h>

    void HsStart() {

     int argc = 1;
    
     char* argv[] = {"ghcDll", NULL}; // argv must end with NULL
    
    // Initialize Haskell runtime
    
    char** args = argv;
    
    hs_init(&argc, &args);
    

    }

    void HsEnd() {

     hs_exit();
    

    }

    A build command on linux might be:

    ghc -c -fPIC StartEnd.c

    ghc -c -fPIC SumRoots.hs

    ghc -shared -dynamic -fPIC -o SumRoots.so SumRoots.o StartEnd.o -lHSrts-ghc7.0.3 -optl-Wl,-rpath,/usr/local/lib/ghc-7.0.3/

    Comment Source:Neil Michell has shown how to call Haskell from another language, in this case R, using a simple C stub. [Calling Haskell from R](http://neilmitchell.blogspot.co.uk/2011/10/calling-haskell-from-r.html) > C stub to be called from R and invoke Haskell. > // StartEnd.c > #include <Rts.h> > void HsStart() { > int argc = 1; > char* argv[] = {"ghcDll", NULL}; // argv must end with NULL > // Initialize Haskell runtime > char** args = argv; > hs_init(&argc, &args); > } > void HsEnd() { > hs_exit(); > } A build command on linux might be: > ghc -c -fPIC StartEnd.c > ghc -c -fPIC SumRoots.hs > ghc -shared -dynamic -fPIC -o SumRoots.so SumRoots.o StartEnd.o -lHSrts-ghc7.0.3 -optl-Wl,-rpath,/usr/local/lib/ghc-7.0.3/
  • 13.
    edited August 2012

    Here is a test programme in C from the fastcgi white paper, that demonstrates fastcgi. I have edited the formatting, replaced Windows line endings with Unix line endings, and fixed a type error. I have not tested this.

    #include <fcgi_stdio.h>
    
    int main(void)
    {
        int count = 0;
        while(FCGI_Accept() >= 0)
        {
            printf("Content-type: text/html\n");
            printf("\n");
            printf("Hello world!<br>\n");
            printf("Request number %d.", count++);
        }
        exit(0);
    }
    

    If this application is called via conventional CGI, then 'count' will always be zero, because a new process is started for each request. If it is called using fastcgi, then 'count' will increment on each request, because the process persists across requests, which is the desired behaviour.

    Comment Source:Here is a test programme in C from the fastcgi white paper, that demonstrates fastcgi. I have edited the formatting, replaced Windows line endings with Unix line endings, and fixed a type error. I have not tested this. #include <fcgi_stdio.h> int main(void) { int count = 0; while(FCGI_Accept() >= 0) { printf("Content-type: text/html\n"); printf("\n"); printf("Hello world!<br>\n"); printf("Request number %d.", count++); } exit(0); } If this application is called via conventional CGI, then 'count' will always be zero, because a new process is started for each request. If it is called using fastcgi, then 'count' will increment on each request, because the process persists across requests, which is the desired behaviour.
  • 14.
    edited August 2012

    All modern servers persist across requests. This problem was solved 11 years ago. The interesting issues are to do with architectures of OS processes and lightweight threads.

    Comment Source:All modern servers persist across requests. This problem was solved 11 years ago. The interesting issues are to do with architectures of OS processes and lightweight threads.
  • 15.

    All modern servers persist across requests.

    Agreed. The problem is that this is achieved at the expense of linking the numeric computation code into a server executable. The problems associated with that approach are described in the Server APIs section of the fastcgi white paper.

    If this server is to be useful to Azimuth code contributors, I believe we require an architecture which minimises the server-dependent interfacing work, and allows possibly buggy contributor's code to be called from the web server, without the risk of bringing the whole web server down. Also, I think I am right in assuming that most potential contributors are mainly interested in what I call "engine room code", and not presentation and interfacing.

    For slider-driven interactive graphics, I think a reasonable architecture would be for the server to pipe slider settings to the stdin of an external process as JSON data, and for the process to pipe its results as JSON data to the server on stdout. This would mean that a contributor could develop and test their code, independently of a Snap server or Haskell compiler. The pipe interface I have described is precisely what fastcgi provides, except that fastcgi is not restricted to using JSON data, of course.

    Comment Source:> All modern servers persist across requests. Agreed. The problem is that this is achieved at the expense of linking the numeric computation code into a server executable. The problems associated with that approach are described in the _Server APIs_ section of the [fastcgi white paper](:http://www.fastcgi.com/drupal/node/6?q=node/15). If this server is to be useful to Azimuth code contributors, I believe we require an architecture which minimises the server-dependent interfacing work, and allows possibly buggy contributor's code to be called from the web server, without the risk of bringing the whole web server down. Also, I think I am right in assuming that most potential contributors are mainly interested in what I call "engine room code", and not presentation and interfacing. For slider-driven interactive graphics, I think a reasonable architecture would be for the server to pipe slider settings to the stdin of an external process as JSON data, and for the process to pipe its results as JSON data to the server on stdout. This would mean that a contributor could develop and test their code, independently of a Snap server or Haskell compiler. The pipe interface I have described is precisely what fastcgi provides, except that fastcgi is not restricted to using JSON data, of course.
  • 16.
    edited August 2012

    Some elegant web architectures (DSL + Framework) include Ur-Web, Grails (Scala is a better Groovy), Borges and Elm. Evan Czaplicki's thesis on Elm is an excellent overview of the issues.

    I ran Grails on my machine for a couple of years which I found to be pretty bombproof on the JVM. Ur has probably inspired snap but I'm only guessing. It's a description at the correct level of abstraction to reason about these things, so I'd say well worth a read.

    There is a vast amount of Web Service, WAI, WSGI, SOAP ad nauseam garbage out there to be avoided.

    Glyn : Yesod has Web Application Interface (WAI) handlers for both fastcgi and, by popular demand, Snap. The popular demand is for reasons you'll have to read up on yourself. I think Yesod is too heavyweight for our purposes ATM. Snap is simpler. There's a speed contest between the two.

    Comment Source:Some elegant web architectures (DSL + Framework) include [Ur-Web](http://www.impredicative.com/ur/), [Grails](http://grails.org) (Scala is a better Groovy), [Borges](http://borges.rubyforge.org/) and [Elm](http://elm-lang.org). Evan Czaplicki's [thesis](http://www.seas.harvard.edu/academics/undergraduate/computer-science/thesis/Czaplicki.pdf) on Elm is an excellent overview of the issues. I ran Grails on my machine for a couple of years which I found to be pretty bombproof on the JVM. Ur has probably inspired snap but I'm only guessing. It's a description at the correct level of abstraction to reason about these things, so I'd say well worth a read. There is a vast amount of Web Service, WAI, WSGI, SOAP ad nauseam garbage out there to be avoided. Glyn : [Yesod](http://yesodweb.com) has Web Application Interface (WAI) handlers for both fastcgi and, by popular demand, Snap. The popular demand is for reasons you'll have to read up on yourself. I think Yesod is too heavyweight for our purposes ATM. Snap is simpler. There's a speed contest between the two.
  • 17.
    edited August 2012

    I think Yesod is too heavyweight for our purposes ATM.

    I too would like to avoid getting bogged down with complicated web architecture stuff. I latched onto fastcgi becuase Julia uses it for web-interactive sessions. The C interface looked pretty simple for running persistent external processes. I now find that, behind the simple interface, there is quite a bit of gubbins going on, that makes it non-trivial to implement the web server side of things. I have installed mod_fastcgi for Apache httpd on my home machine, but have not got to the stage where I can run one of the examples that come with the fastcgi sources. I came across an interesting discussion that covers fastcgi, and many other ways to get a website running with heavy work farmed out to persistent external processes.

    I still think that contributor's code should run outside of the main web server's address space, i.e. as external processes. If contributor's code crashes or misbehaves, then that should only affect their interactive model, not the whole site. Is it possible to run multiple Snaplets that communicate to a master Snap server?

    Comment Source:> I think Yesod is too heavyweight for our purposes ATM. I too would like to avoid getting bogged down with complicated web architecture stuff. I latched onto fastcgi becuase Julia uses it for web-interactive sessions. The C interface looked pretty simple for running persistent external processes. I now find that, behind the simple interface, there is quite a bit of gubbins going on, that makes it non-trivial to implement the web server side of things. I have installed mod_fastcgi for Apache httpd on my home machine, but have not got to the stage where I can run one of the examples that come with the fastcgi sources. I came across an interesting [discussion](http://www.vmunix.com/mark/blog/archives/2006/01/02/fastcgi-scgi-and-apache-background-and-future/) that covers fastcgi, and many other ways to get a website running with heavy work farmed out to persistent external processes. I still think that contributor's code should run outside of the main web server's address space, i.e. as external processes. If contributor's code crashes or misbehaves, then that should only affect their interactive model, not the whole site. Is it possible to run multiple Snaplets that communicate to a master Snap server?
  • 18.

    I agree on all points. Yep, you can have sub-snaplets which fits with the "single page model" for websites using Ajax. Evan from Elm has written up a means for implementing Ajax with Elm.

    Comment Source:I agree on all points. Yep, you can have sub-snaplets which fits with the "single page model" for websites using Ajax. Evan from Elm has written up a means for implementing Ajax with Elm.
  • 19.

    Hey everyone! Think your server could handle a WordPress instance Jim? Where is it running? The ideal server in my mind would live on a college or large institutional network somewhere so that there would be no sudden bandwidth fee surprises if a blog article hits the big-time. The free wordpress.org site has unlimited bandwith AFAIK

    Comment Source:Hey everyone! Think your server could handle a WordPress instance Jim? Where is it running? The ideal server in my mind would live on a college or large institutional network somewhere so that there would be no sudden bandwidth fee surprises if a blog article hits the big-time. The free wordpress.org site has unlimited bandwith AFAIK
  • 20.

    Hi Allan, The server costs ~£200 for 2 years on bluehost.com. I agree an Azimuth server should be on a college or institutional network with a team of admins, not just Andrew lumbered with it all. We can use 67.20.108.116 to prototype apps, wikis and blogs until we exceed its ooomph.

    I'm sure Snap could interface to php (Wordpress) just like Apache does. I built a website in Drupal (php) but it was arcane and the documentation was no help when it came to debugging. I dumped it. Apparently Glyn's business partner Castro had a similar experience.

    IMO any "unlimited" claims from ISPs should be banned by the ASA (UK advertising standards authority); somewhere in the T&Cs I've always found a "reasonable use" get out. You'd have to check bluehost.com's charges but the comics were saying they offer the best bang per buck for what they do when I signed up.

    Comment Source:Hi Allan, The server costs ~£200 for 2 years on bluehost.com. I agree an Azimuth server should be on a college or institutional network with a team of admins, not just Andrew lumbered with it all. We can use 67.20.108.116 to prototype apps, wikis and blogs until we exceed its ooomph. I'm sure Snap could interface to php (Wordpress) just like Apache does. I built a website in Drupal (php) but it was arcane and the documentation was no help when it came to debugging. I dumped it. Apparently Glyn's business partner Castro had a similar experience. IMO any "unlimited" claims from ISPs should be banned by the ASA (UK advertising standards authority); somewhere in the T&Cs I've always found a "reasonable use" get out. You'd have to check bluehost.com's charges but the comics were saying they offer the best bang per buck for what they do when I signed up.
  • 21.

    I've now built the default Snap server with working tutorial to have a look at; and non-working blog link (due to building in a sandbox while there is a Snap file hierarchy convention).

    Allan or any other Azimuthers who might be interested are welcome to have account on the server. Just email me or private msg on google+ to +Jim Stuttard.

    The server seems to be being shut down sporadically by the ISP. It didn't happen today and I don't have a guaranteed correct error.log so this may well keep happening until I find the cause or raise a support ticket. So please bear with us for a few days if the site is down. I haven't time to post an "Under construction" page ATM.

    Glyn and Allan, the demo Snap website and blog code is here if you have time to look at it.

    Comment Source:I've now built the default Snap server with working tutorial to have a look at; and non-working blog link (due to building in a sandbox while there is a Snap file hierarchy convention). Allan or any other Azimuthers who might be interested are welcome to have account on the server. Just email me or private msg on google+ to +Jim Stuttard. The server seems to be being shut down sporadically by the ISP. It didn't happen today and I don't have a guaranteed correct error.log so this may well keep happening until I find the cause or raise a support ticket. So please bear with us for a few days if the site is down. I haven't time to post an "Under construction" page ATM. Glyn and Allan, the demo Snap website and blog code is [here](http://github.com/snapframework-snap-website) if you have time to look at it.
  • 22.

    Just for information: this forum is running on a virtual machine hosted at my university (by virtue of being the same underlying code as a forum I run for my students). There is a blog which isn't used but could be as part of the same software. The only bit on a VPS with a hosting company is the azimuth wiki. Then there's John's wordpress blog hosted by wordpress.

    Comment Source:Just for information: this forum is running on a virtual machine hosted at my university (by virtue of being the same underlying code as a forum I run for my students). There is a blog which isn't used but could be as part of the same software. The only bit on a VPS with a hosting company is the azimuth wiki. Then there's John's wordpress blog hosted by wordpress.
  • 23.
    edited August 2012

    Hi Andrew,

    Thanks for the info. I need it to get some perspective on how things work at the moment.

    I've only set up this server so we can try lots of climate or other models in different languages. Most people's websites are on shared hosts but I need at least shell access to run multiple compilers.

    After 50 emails to buy and transfer my domain name and half a dozen support tickets on bluehost.com to get port 8000 opened installing a Snap server was technically easy, I didn't want to burden you.

    As I can't even learn how to format code in blog posts properly, I'll leave Wordpress to you and John :)

    Comment Source:Hi Andrew, Thanks for the info. I need it to get some perspective on how things work at the moment. I've only set up this server so we can try lots of climate or other models in different languages. Most people's websites are on shared hosts but I need at least shell access to run multiple compilers. After 50 emails to buy and transfer my domain name and half a dozen support tickets on bluehost.com to get port 8000 opened installing a Snap server was technically easy, I didn't want to burden you. As I can't even learn how to format code in blog posts properly, I'll leave Wordpress to you and John :)
  • 24.

    I think Andrew hates Wordpress; I use it because it works without me having to know how it works.

    When I get back to UCR, I'll look into getting Jim Stuttard an account there. I'm not sure how advantageous that'll be, but I should at least try.

    Comment Source:I think Andrew hates Wordpress; I use it because it works without me having to know how it works. When I get back to UCR, I'll look into getting Jim Stuttard an account there. I'm not sure how advantageous that'll be, but I should at least try.
  • 25.

    I think Andrew hates Wordpress

    That's a bit strong! I'm actually an author on a Wordpress installation (about TeX) and have set up a Wordpress installation of my own (albeit to test a MathML plugin rather than to have an actual blog). What I really hate are systems that force you to have Maths-as-images. My real bugbear is non-accessible mathematics. If we intend using blogs to communicate mathematics, why do we cripple ourselves by making it both ugly and inaccessible?

    But seriously, I maintain this forum and the wiki as my contribution to this project - I'm in full agreement with its aims but don't have the expertise to contribute mathematically (though the recent stuff on infinite dimensional manifolds might change that) so this is what I can do. If, while I do it, I can secretly convince you all of the necessity of MathML, so much the better.

    My comments pointing out the blogging possibilities of this place should be taken as just to ensure that the azimuth team have all the information that they need to make the right decision. If it is felt that the current Azimuth blog has limitations, it's another possibility to use this place than for John to try to maintain his own Wordpress installation at UCR. Of course, there may be other reasons why that would be preferable, or even to have a completely new installation entirely.

    Comment Source:> I think Andrew hates Wordpress That's a *bit* strong! I'm actually an author on a Wordpress installation (about TeX) and have set up a Wordpress installation of my own (albeit to test a MathML plugin rather than to have an actual blog). What I *really* hate are systems that force you to have Maths-as-images. My real bugbear is non-accessible mathematics. If we intend using blogs to communicate mathematics, why do we cripple ourselves by making it both ugly and inaccessible? But seriously, I maintain this forum and the wiki as my contribution to this project - I'm in full agreement with its aims but don't have the expertise to contribute mathematically (though the recent stuff on infinite dimensional manifolds might change that) so this is what I can do. If, while I do it, I can secretly convince you all of the necessity of MathML, so much the better. My comments pointing out the blogging possibilities of this place should be taken as just to ensure that the azimuth team have all the information that they need to make the right decision. If it is felt that the current Azimuth blog has limitations, it's another possibility to use this place than for John to try to maintain his own Wordpress installation at UCR. Of course, there may be other reasons why that would be preferable, or even to have a completely new installation entirely.
  • 26.

    There is now half a dummy Burgers UI intermittently viewable on the server. bluehost have managed to hose the server and still haven't got their act together. Glyn kindly looked at the graph data - I'd left a rougue line in the data file.

    Comment Source:There is now half a dummy Burgers UI intermittently viewable on the server. bluehost have managed to hose the server and still haven't got their act together. Glyn kindly looked at the graph data - I'd left a rougue line in the data file.
  • 27.

    Sorry to exaggerate your position, Andrew! I'm torn between my desire to make things wonderful, my desire to stick with something that's sort of working already, and my desire not to think about this stuff at all.

    Comment Source:Sorry to exaggerate your position, Andrew! I'm torn between my desire to make things wonderful, my desire to stick with something that's sort of working already, and my desire not to think about this stuff at all.
  • 28.

    So the server is still down Jim? Is it a dedicated VM that you have root access etc to, or is it a shared resource?

    It could be worth looking at Hakyll for authoring static content, if Snap proves too much of a burden to learn. You could still serve the content via Snap, or something more traditional like Apache or nginx.

    Comment Source:So the server is still down Jim? Is it a dedicated VM that you have root access etc to, or is it a shared resource? It could be worth looking at [Hakyll](http://jaspervdj.be/hakyll/) for authoring static content, if Snap proves too much of a burden to learn. You could still serve the content via Snap, or something more traditional like Apache or nginx.
  • 29.
    edited August 2012

    I've restarted the server. Why it was brought down overnight I don't know.

    Bluehost rebooted the server on Friday and had obviously opened port 8000 by hand as it closed. It took until yesterday for them to reopen the requested ports. Snap had been running fine for a number of days.

    I haven't yet set up a cron (system job scheduler) for @reboot but will do so today.

    The cheap bluehost deal is shell access on shared load-balanced servers.

    Hakyll is great, I've built a couple of static sites with it. Snap isn't yet the problem. My home server has worked flawlessly for a couple of years. I learned to hate mod-perl and switched to Tomcat years ago; Glyn has started to discover some of the infelicities of Apache. Learning FFI (foreign function interface for calling programs in other computer languages) is the somewhat greater challenge.

    Many thanks for the input, it's much appreciated.

    Comment Source:I've restarted the server. Why it was brought down overnight I don't know. Bluehost rebooted the server on Friday and had obviously opened port 8000 by hand as it closed. It took until yesterday for them to reopen the requested ports. Snap had been running fine for a number of days. I haven't yet set up a cron (system job scheduler) for @reboot but will do so today. The cheap bluehost deal is shell access on shared load-balanced servers. Hakyll is great, I've built a couple of static sites with it. Snap isn't yet the problem. My home server has worked flawlessly for a couple of years. I learned to hate mod-perl and switched to Tomcat years ago; Glyn has started to discover some of the infelicities of Apache. Learning FFI (foreign function interface for calling programs in other computer languages) is the somewhat greater challenge. Many thanks for the input, it's much appreciated.
  • 30.
    edited August 2012

    I just was off for too long but I think this is going in the wrong direction from Web 2.0 to Web 1.0 . So I like they idea of moving towards using Web 2.0 applications for the things we can. It is such a waste of time to do this trust me I've done it and been commanded to do it against my will many times. But anyhow kudos for doing it so far!

    Sage has all the basic numerical libraries you can think of LA* plus it supports compilation to C or C++ on the cell level or a whole package which is incredibly fast and also has built in MPI support so its definitely built for scalability. I've tried XWiki and I was fond of it but it also is more complex to use for ordnary people. I've tried twice and didn't convince people in some projects.

    So I'd stay with web 2.0 and try to ameliorate the tools we use and then try to move towards the semantic web step by step (aka web 3.0)

    more later....

    Comment Source:I just was off for too long but I think this is going in the wrong direction from Web 2.0 to Web 1.0 . So I like they idea of moving towards using Web 2.0 applications for the things we can. It is such a waste of time to do this trust me I've done it and been commanded to do it against my will many times. But anyhow kudos for doing it so far! Sage has all the basic numerical libraries you can think of LA* plus it supports compilation to C or C++ on the cell level or a whole package which is incredibly fast and also has built in MPI support so its definitely built for scalability. I've tried XWiki and I was fond of it but it also is more complex to use for ordnary people. I've tried twice and didn't convince people in some projects. So I'd stay with web 2.0 and try to ameliorate the tools we use and then try to move towards the semantic web step by step (aka web 3.0) more later....
  • 31.

    Jim just one correction on png: It was developed by World Wide Web consortium as a reaction on the .gif IPR issues. I was on w3c when this happened, but he might have been part of that group. So partly right ;-)

    Comment Source:Jim just one correction on png: It was developed by World Wide Web consortium as a reaction on the .gif IPR issues. I was on w3c when this happened, but he might have been part of that group. So partly right ;-)
  • 32.
    edited August 2012

    Interactive site for Sage sniplets is a good example of how to use Sage single server on a site

    i talked about this on another thread with John, on another thread, so I just wanted to mention it here as well. also Sage has lots of pagages including BLAS LAPack and 70 more , so its a good idea 'to check that list before doing any major development.

    the thing i didnt know if Snap support adding javascript libraries? (the site above was built in this way.)

    Comment Source:[Interactive site for Sage sniplets](http://interact.sagemath.org/top-rated-posts) is a good example of how to use Sage single server on a site i talked about this on another thread with John, on another thread, so I just wanted to mention it here as well. also Sage has [lots of pagages including BLAS LAPack and 70 more ](http://www.sagemath.org/links-components.html), so its a good idea 'to check that list before doing any major development. the thing i didnt know if Snap support adding javascript libraries? (the site above was built in this way.)
  • 33.

    It took me 5 minutes to put up the interactive co-albedo example I wrote some time ago. See

    Coalbedo feedback

    So this was simple. Im gonna try others more complicated. I actually made it available under creative commons CC SA but if someone protests I can change this :-)

    Comment Source:It took me 5 minutes to put up the interactive co-albedo example I wrote some time ago. See [Coalbedo feedback](http://interact.sagemath.org/node/53) So this was simple. Im gonna try others more complicated. I actually made it available under creative commons CC SA but if someone protests I can change this :-)
  • 34.
    edited August 2012

    Staffan, I know that Sage provides a useful web-interactive environment for numeric computing, without messing about with specialist web servers and so on. But there are many scientists and other potential Azimuth code contributors that do not know Sage, and do not feel a strong enough need to learn it to a sufficient level of competence to convert their code to Sage. My own preference for numeric computing is C++. Other people may have useful code written in, say, Java, Fortran or Haskell. What Jim and I would like is to have the server run contributor's code written in any language we have a compiler for.

    There is also the matter of the user interface for an interactive modelling web page, which allows a user to set input parameters, and observe results via graphs and so on when they run the model. Users of such an interactive model would not generally be coders, but presumably they know enough of the science to understand the model's inputs and outputs, or they wish to learn. So I would not expect users to have to write Sage code in order to interact with a model.

    The server-client architecture Jim and I are working on is this (Jim may disagree on details).

    Master server
    This is the entry point for client requests, and provides links to various models. It farms out the numeric work for particular models to sub-servers.
    Sub-server
    Each model runs via a separate sub-server process, communicating with the master server over a socket. This means that potentially buggy numeric code can crash without compromising the master server. For the best compute efficiency, numeric code (in whatever language) is linked in to the sub-server, using a Foreign Function Interface (FFI), and runs in the sub-server's address space.
    Sub-server-to-model interface
    Ideally, functions that define the model can be called from the sub-server without the model designer needing to know much about the presentation of the model in the user's web browser. To make this work, someone would need to write some Haskell, HTML, Javascript etc., based on some interface provided from from the numeric computing model. A typical interface would parse user input into numeric values for the model, and convert output arrays or lists of graph points into a web-friendly format, e.g. JSON (Javascript Object Notation).
    Client interface and presentation
    Javascript and/or HTML5 in the browser is used as a presentation layer. A typical browser interface would have some sliders for setting model parameters, and one or more graphics panels for displaying the model output. The presentation layer takes care of things like graph axes and grids.
    Comment Source:Staffan, I know that Sage provides a useful web-interactive environment for numeric computing, without messing about with specialist web servers and so on. But there are many scientists and other potential Azimuth code contributors that do not know Sage, and do not feel a strong enough need to learn it to a sufficient level of competence to convert their code to Sage. My own preference for numeric computing is C++. Other people may have useful code written in, say, Java, Fortran or Haskell. What Jim and I would like is to have the server run contributor's code written in any language we have a compiler for. There is also the matter of the user interface for an interactive modelling web page, which allows a user to set input parameters, and observe results via graphs and so on when they run the model. Users of such an interactive model would not generally be coders, but presumably they know enough of the science to understand the model's inputs and outputs, or they wish to learn. So I would not expect users to have to write Sage code in order to interact with a model. The server-client architecture Jim and I are working on is this (Jim may disagree on details). Master server : This is the entry point for client requests, and provides links to various models. It farms out the numeric work for particular models to sub-servers. Sub-server : Each model runs via a separate sub-server process, communicating with the master server over a socket. This means that potentially buggy numeric code can crash without compromising the master server. For the best compute efficiency, numeric code (in whatever language) is linked in to the sub-server, using a Foreign Function Interface (FFI), and runs in the sub-server's address space. Sub-server-to-model interface : Ideally, functions that define the model can be called from the sub-server without the model designer needing to know much about the presentation of the model in the user's web browser. To make this work, someone would need to write some Haskell, HTML, Javascript etc., based on some interface provided from from the numeric computing model. A typical interface would parse user input into numeric values for the model, and convert output arrays or lists of graph points into a web-friendly format, e.g. JSON (Javascript Object Notation). Client interface and presentation : Javascript and/or HTML5 in the browser is used as a presentation layer. A typical browser interface would have some sliders for setting model parameters, and one or more graphics panels for displaying the model output. The presentation layer takes care of things like graph axes and grids.
  • 35.

    Certainly end users shouldn't have to learn Sage or any other language to interact with the models we create. But I don't need to know Sage to interact with this Sage-based model of a paper airplane in flight, for example.

    So maybe your main point is that you want a server that can run software in lots of different languages?

    Comment Source:Certainly end users shouldn't have to learn Sage _or any other language_ to interact with the models we create. But I don't need to know Sage to interact with [this Sage-based model of a paper airplane in flight](http://interact.sagemath.org/node/48), for example. So maybe your main point is that you want a server that can run software in lots of different languages?
  • 36.

    Oops! I took too long posting, so our posts crossed over.

    It looks like Sage can present a model in the way I would like, i.e. slider inputs with some meaning attached to each, and graphs that update on slider changes. There still remains the problem that, if I want to contribute a model implemented and presented using Sage, I will need to learn Sage fairly well. I am not afraid of learning new languages, but I know many experienced coders that would not bother. A bit of a barrier, I think.

    Comment Source:Oops! I took too long posting, so our posts crossed over. It looks like Sage can present a model in the way I would like, i.e. slider inputs with some meaning attached to each, and graphs that update on slider changes. There still remains the problem that, if I want to contribute a model implemented and presented using Sage, I will need to learn Sage fairly well. I am not afraid of learning new languages, but I know many experienced coders that would not bother. A bit of a barrier, I think.
  • 37.

    I should point out that Jim intends to have several interactive computing environments available on his server, including Sage. The idea is to be inclusive.

    Comment Source:I should point out that Jim intends to have several interactive computing environments available on his server, including Sage. The idea is to be inclusive.
  • 38.
    edited August 2012

    Hi Staffan,

    If you send me an email address I can send you a login for the server. Bluehost offers the usual LAMP services running on RHEL/Centos.

    There is a full Python installation. I have installed the rpm's for NumPy and SciPy but not LAPACK and BLAS yet.

    I asked Bluehost to open ports 8000-8003 tcp/udp in out and 8100-8103 tcp/udp out so we can run different servers on different ports, sandboxed by Snap. I have a ~/public_html/.htaccess file which redirect from Apache on port 80 to Snap on port 8000.

    Please feel free to install Sage and point it to port 8002 or 8003 (not 8000 or 8001 as Snap is using those).

    stuttard.org:8002 (say) should get you to your installation until we have a single page website which seamlessly redirects to Sage and other applications.

    Snap templates can use any javascript file in its /static directory. There is a terse pdf description of how Snap works here.

    Somewhere on the forum I read a post which suggested that whichever Community Climate Model was rewritten from Fortran into Python was too complicated for people to use. I disagree and would very much like to run the Python CCM if 3GB of memory is sufficient. WDYT?

    Comment Source:Hi Staffan, If you send me an email address I can send you a login for the server. Bluehost offers the usual LAMP services running on RHEL/Centos. There is a full Python installation. I have installed the rpm's for NumPy and SciPy but not LAPACK and BLAS yet. I asked Bluehost to open ports 8000-8003 tcp/udp in out and 8100-8103 tcp/udp out so we can run different servers on different ports, sandboxed by Snap. I have a ~/public_html/.htaccess file which redirect from Apache on port 80 to Snap on port 8000. Please feel free to install Sage and point it to port 8002 or 8003 (not 8000 or 8001 as Snap is using those). stuttard.org:8002 (say) should get you to your installation until we have a single page website which seamlessly redirects to Sage and other applications. Snap templates can use any javascript file in its /static directory. There is a terse pdf description of how Snap works [here](http://steve.vinoski.net/pdf/IC-Snap_Framework.pdf). Somewhere on the forum I read a post which suggested that whichever Community Climate Model was rewritten from Fortran into Python was too complicated for people to use. I disagree and would very much like to run the Python CCM if 3GB of memory is sufficient. WDYT?
  • 39.
    edited August 2012

    Jim wrote:

    Somewhere on the forum I read a post which suggested that whichever Community Climate Model was rewritten from Fortran into Python was too complicated for people to use. I disagree and would very much like to run the Python CCM if 3GB of memory is sufficient. WDYT?

    Most likely we were talking about this:

    http://clearclimatecode.org/gistemp/

    of course you could try to get it up and running (I haven't, so I cannot warn you about anything), if you don't get easily frustrated ;-)

    Comment Source:Jim wrote: <blockquote> <p> Somewhere on the forum I read a post which suggested that whichever Community Climate Model was rewritten from Fortran into Python was too complicated for people to use. I disagree and would very much like to run the Python CCM if 3GB of memory is sufficient. WDYT? </p> </blockquote> Most likely we were talking about this: [http://clearclimatecode.org/gistemp/](http://clearclimatecode.org/gistemp/) of course you could try to get it up and running (I haven't, so I cannot warn you about anything), if you don't get easily frustrated ;-)
  • 40.

    Thanks for the link Tim. Given Alan Perlis's tryptich of programmer virtues: laziness, impatience, arrogance, I accept the frustrations as inevitable :(. I'm hoping some Azimuth Pythonista will have a go at gistemp. I'm currently on a Fortran kick, reading Isaac Helm's excellently structured and documented code and trying to learn the MOM algorithms.

    Comment Source:Thanks for the link Tim. Given Alan Perlis's tryptich of programmer virtues: laziness, impatience, arrogance, I accept the frustrations as inevitable :(. I'm hoping some Azimuth Pythonista will have a go at gistemp. I'm currently on a Fortran kick, reading Isaac Helm's excellently structured and documented code and trying to learn the MOM algorithms.
  • 41.
    edited August 2012

    Allan Erskine emailed me with an offer to write a build script and makefile for production and dev servers. That will be great.

    There are currently 2 instances of Snap executables: a supposedly production version, built on July 17th, called azimuth and a development version (which automatically recompiles on any code changes - woo!) called test.

    Anybody can make their own default Snap installation. Just make a directory under public_html like myservername, cd into it and type snap init.

    Each Snap instance is running in its own Haskell sandbox. Like the Java tool, Maven's pom files, this use of cabal-dev is a big practical step for Haskell in dealing with dependency hell. It has the drawback that each project (as with Maven) has to install its own full set of dependencies (at least until we've installed the Haskell Platform (std libraries). This is a worthwhile price to pay IMO.

    The bad news is that I've hosed the azimuth instance I made on July 17th and which ran fine for 3 days until (from a guess at a log entry) Bluehost rebooted the shared OS instance. I'll have to disable the myriad of redundant template files to check that it's my bad code.

    The good news is that simple Haskell FFI works fine (FfiEx,SecsFrom1970 etc) pretty much OOTB. I've collected the relevant links for an azimuth-specific tutorial. If anybody's interested I'll write a page.

    Bluehost also uses the well-known, undocumented, management console kludge, CPanel. This is the only way to set cron jobs but they don't support the @reboot command. I've written a restart.sh to test whether the server was up every half hour but have deleted the cron job which runs it. CPanel is accessible at bluehost.com in the CPanel login box as stuttard.org and the ordinary password.

    So if there are any other script kiddies, server admins, CPanel gurus, or people who can interpret unix etc log files out there and who are willing to help, please email me for a login.

    Comment Source:Allan Erskine emailed me with an offer to write a build script and makefile for production and dev servers. That will be great. There are currently 2 instances of Snap executables: a supposedly production version, built on July 17th, called azimuth and a development version (which automatically recompiles on any code changes - woo!) called test. Anybody can make their own default Snap installation. Just make a directory under public_html like myservername, cd into it and type snap init. Each Snap instance is running in its own Haskell sandbox. Like the Java tool, Maven's pom files, this use of cabal-dev is a big practical step for Haskell in dealing with dependency hell. It has the drawback that each project (as with Maven) has to install its own full set of dependencies (at least until we've installed the Haskell Platform (std libraries). This is a worthwhile price to pay IMO. The bad news is that I've hosed the azimuth instance I made on July 17th and which ran fine for 3 days until (from a guess at a log entry) Bluehost rebooted the shared OS instance. I'll have to disable the myriad of redundant template files to check that it's my bad code. The good news is that simple Haskell FFI works fine (FfiEx,SecsFrom1970 etc) pretty much OOTB. I've collected the relevant links for an azimuth-specific tutorial. If anybody's interested I'll write a page. Bluehost also uses the well-known, undocumented, management console kludge, CPanel. This is the only way to set cron jobs but they don't support the @reboot command. I've written a restart.sh to test whether the server was up every half hour but have deleted the cron job which runs it. CPanel is accessible at bluehost.com in the CPanel login box as stuttard.org and the ordinary password. So if there are any other script kiddies, server admins, CPanel gurus, or people who can interpret unix etc log files out there and who are willing to help, please email me for a login.
  • 42.

    Jim/folks --- here is what I had in mind for the build/deploy script, partly inspired by my own experiences and partly by some fine examples from the open source community (eg Julia) -- my goal is to satisfy three criteria:

    • inclusive (as was mentioned above): lots of people should be able to contribute to this without trodding on each others toes nor being constrained into any particular ideal
    • reproducible: be able to reproduce the (nascent) Azimuth Code Project site in an automated fashion, ideally from source control, independently of which server it is hosted on -- this should help people feel that their efforts are protected
    • reliable: support multiple concurrent versions of the site --- the main 'release' version that everyone sees, and development versions where people can implement new things without fear of breaking old things (and which are automatically checked for broken links etc before going live)

    I feel I can sense some momentum behind making this server work, so am happy to help out in any way I can, esp so given that Jim has stumped up the bill for this! Perhaps we should eventually include a Flattr button to pay bills in future (should someone feel that the site has any merit!)

    Comment Source:Jim/folks --- here is what I had in mind for the build/deploy script, partly inspired by my own experiences and partly by some fine examples from the open source community (eg Julia) -- my goal is to satisfy three criteria: * inclusive (as was mentioned above): lots of people should be able to contribute to this without trodding on each others toes nor being constrained into any particular ideal * reproducible: be able to reproduce the (nascent) Azimuth Code Project site in an automated fashion, ideally from source control, independently of which server it is hosted on -- this should help people feel that their efforts are protected * reliable: support multiple concurrent versions of the site --- the main 'release' version that everyone sees, and development versions where people can implement new things without fear of breaking old things (and which are automatically checked for broken links etc before going live) I feel I can sense some momentum behind making this server work, so am happy to help out in any way I can, esp so given that Jim has stumped up the bill for this! Perhaps we should eventually include a Flattr button to pay bills in future (should someone feel that the site has any merit!)
  • 43.

    I imagined this would be a loaded issue, so let me address some now. John did you see that I put the co-albedo example on

    Coalbedo feedback

    its on the same page as the plane paper flight plot. When u press "evaluate" u can change the values with a slider as usual in Sage. So I'd say we use Sage for simple demos and as long as the public Sage notebook doesnt allow us to have public worksheets right now. It might even be so good that we end up installing it on our server or Instiki even.

    Glyn and Jim: The programmers dilemma is just this! I am also learning Sage but as it they use Python as base its pretty straight-forward as Python looks like "pseudo-code" (code used to show algorithms ). And Jim if u want to use C++,C, Java or C its straight-forward to use immediately with Sage and also you can compile Sage, your libs with Cython, which u can use without Sage as well. So my point is I don't mind any language you wanna use, as long as they are open source or at least the libraries are.

    Another issue is (warning here comes Instiki bashing :-)) is when you try to use/develop open source ensure that it has a large dynamic developer community. Instiki for me would never have been a choice - as it was developed first by DHH (when he did Rails - as a prototype - and then it was adopted by some in the math community and has one developer :-(.

    So use any current language/api/server/application/framework you like if it is open source and is mature, eg passed not just 1.0 but 2 or 3.0 and have a host of applications . So my principles would rule out Snap as its in 0.6 (and instiki...). and think on 3 things; usability, usability and usability !

    So I think you are aiming too low, we should use higher level components instead and Ill return to this when u react too this ;-)

    Comment Source:I imagined this would be a loaded issue, so let me address some now. John did you see that I put the co-albedo example on [Coalbedo feedback](http://interact.sagemath.org/node/53) its on the same page as the plane paper flight plot. When u press "evaluate" u can change the values with a slider as usual in Sage. So I'd say we use Sage for simple demos and as long as the public Sage notebook doesnt allow us to have public worksheets right now. It might even be so good that we end up installing it on our server or Instiki even. Glyn and Jim: The programmers dilemma is just this! I am also learning Sage but as it they use Python as base its pretty straight-forward as Python looks like "pseudo-code" (code used to show algorithms ). And Jim if u want to use C++,C, Java or C its straight-forward to use immediately with Sage and also you can compile Sage, your libs with [Cython](http://cython.org), which u can use without Sage as well. So my point is I don't mind any language you wanna use, as long as they are open source or at least the libraries are. Another issue is (warning here comes Instiki bashing :-)) is when you try to use/develop open source ensure that it has a large dynamic developer community. Instiki for me would never have been a choice - as it was developed first by DHH (when he did Rails - as a prototype - and then it was adopted by some in the math community and has one developer :-(. So use any current language/api/server/application/framework you like if it is open source and is mature, eg passed not just 1.0 but 2 or 3.0 and have a host of applications . So my principles would rule out Snap as its in 0.6 (and instiki...). and think on 3 things; usability, usability and usability ! So I think you are aiming too low, we should use higher level components instead and Ill return to this when u react too this ;-)
  • 44.
    edited August 2012

    Hi Staffan,

    Snap is actually the Snapframework - just like any other framework, except it's type-safe, (apart from my code) robust, scalable and fast.

    The installed Haskell Snap version os 0.9.0.1. I intend to adapt Chris Smith's gloss-web Snap framework to whatever UI anybody wants.

    Snap has the heist templating mechanism which hides all the xhtml bureaucracy in a simple markdown format; it doesn't yet support taxonomies or agents but apart from that it's as semantic web as any other web framework.

    Chris built it for his interactive graphics, animation and simulation programming system Haskell for Kids; the user site is here I just copy and paste my data into the editor surrounded by plot =[...] and up pops my graph. Much more convenient that gnuplot.

    As I think I've pointed out, we can open multiple ports on the firewall and thus run several severs (modulo memory) if there is an open source Sage server.

    Snap automatically loads any files in ~/public_html/bin/azimuth/static including css and js files so you can serve javascript pointing in either direction as with Elm.

    The climate code I'm studying, some of which I might want to serve up on the site, is all Fortran. Could Sage handle that? When you mention Python's C interfaces you too appear to be going backward from whatever a web-3.0 ideal is supposed to be! There's no escaping the plumbing if you want high-assurance middleware :)

    Comment Source:Hi Staffan, Snap is actually the Snapframework - just like any other framework, except it's type-safe, (apart from my code) robust, scalable and fast. The installed Haskell Snap version os 0.9.0.1. I intend to adapt Chris Smith's [gloss-web](https://github.com/cdsmith/gloss-web) Snap framework to whatever UI anybody wants. Snap has the heist templating mechanism which hides all the xhtml bureaucracy in a simple markdown format; it doesn't yet support taxonomies or agents but apart from that it's as semantic web as any other web framework. Chris built it for his interactive graphics, animation and simulation programming system [Haskell for Kids](http://cdsmith.wordpress.com/2011/08/16/haskell-for-kids-week-1/); the user site is [here](http://dac4.designacourse.com:8000/) I just copy and paste my data into the editor surrounded by plot =[...] and up pops my graph. Much more convenient that gnuplot. As I think I've pointed out, we can open multiple ports on the firewall and thus run several severs (modulo memory) if there is an open source Sage server. Snap automatically loads any files in ~/public_html/bin/azimuth/static including css and js files so you can serve javascript pointing in either direction as with [Elm](elm-lang.org). The climate code I'm studying, some of which I might want to serve up on the site, is all Fortran. Could Sage handle that? When you mention Python's C interfaces you too appear to be going backward from whatever a web-3.0 ideal is supposed to be! There's no escaping the plumbing if you want high-assurance middleware :)
  • 45.
    edited August 2012

    I've installed Jenkins on the server and Allan's noticed and is working on a deployment which will allow continuous integration (CI) for azimuth application developers. With CI a version control system (VCS) manages all updates and a CI server automatically recompiles the source code from your home machine.

    Snap already has a form of CI when the instance is built with -fdevelopment any changes in source files in the Snap instance hierarchy are automatically recompiled. V. cool.

    I use git and cabal-dev as my tools. Unless anybody objects either Allan, Glyn or I will install a git server. I used to love subversion when it came out. git is much more popular and I've forgotten how to use svn. Alternative suggestions are welcome.

    BTW Doesn't Azimuth need a recognisable colour-scheme, typeface set and logo? What colour shall we paint the garden shed?

    Comment Source:I've installed Jenkins on the server and Allan's noticed and is working on a deployment which will allow continuous integration (CI) for azimuth application developers. With CI a version control system (VCS) manages all updates and a CI server automatically recompiles the source code from your home machine. Snap already has a form of CI when the instance is built with -fdevelopment any changes in source files in the Snap instance hierarchy are automatically recompiled. V. cool. I use git and cabal-dev as my tools. Unless anybody objects either Allan, Glyn or I will install a git server. I used to love subversion when it came out. git is much more popular and I've forgotten how to use svn. Alternative suggestions are welcome. BTW Doesn't Azimuth need a recognisable colour-scheme, typeface set and logo? What colour shall we paint the garden shed?
  • 46.
    edited August 2012

    Great Staffan, found you on Google+ and noticed you'd posted an answer to my Fortran question.

    I followed one of the links you posted and found this about Fortran from Cython:

    Without question the most error-prone and dark corner-filled part of fwrap is the build system. It’s based off of numpy’s distutils, but it is very fragile. Fwrap demands a lot from a build system: (1) generate C, Fortran and Cython headers from an external python script, (2) compile Fortran 90 sources with module dependencies, (3) generate .c files from a .pyx, and (4) compile all the fortran and C source into a Python extension module. Now that it is time to incorporate full-on Fortran 90 support in fwrap, distutils just plain doesn’t cut it. I can either spend my time monkey patching things together or move to another build system.

    Guess what I’ve decided to do.

    Comment Source:Great Staffan, found you on Google+ and noticed you'd posted an answer to my Fortran question. I followed one of the links you posted and found this about [Fortran from Cython](http://fortrancython.wordpress.com/): > Without question the most error-prone and dark corner-filled part of fwrap is the build system. It’s based off of numpy’s distutils, but it is very fragile. Fwrap demands a lot from a build system: (1) generate C, Fortran and Cython headers from an external python script, (2) compile Fortran 90 sources with module dependencies, (3) generate .c files from a .pyx, and (4) compile all the fortran and C source into a Python extension module. Now that it is time to incorporate full-on Fortran 90 support in fwrap, distutils just plain doesn’t cut it. I can either spend my time monkey patching things together or move to another build system. > Guess what I’ve decided to do.
  • 47.

    Jim wrote:

    I use git and cabal-dev as my tools. Unless anybody objects either Allan, Glyn or I will install a git server. I used to love subversion when it came out. git is much more popular and I've forgotten how to use svn. Alternative suggestions are welcome.

    I use git too, but prefer github.com to running my own server and would recommend this to others here. Installing a git server seems redundant these days. We can create an azimuth account on github for free supporting unlimited repositories/collaborators. It may end up being a good way to attract more coders too (anyone who's anyone etc..)

    Comment Source:Jim wrote: > I use git and cabal-dev as my tools. Unless anybody objects either Allan, Glyn or I will install a git server. I used to love subversion when it came out. git is much more popular and I've forgotten how to use svn. Alternative suggestions are welcome. I use git too, but prefer github.com to running my own server and would recommend this to others here. Installing a git server seems redundant these days. We can create an azimuth account on github for free supporting unlimited repositories/collaborators. It may end up being a good way to attract more coders too (anyone who's anyone etc..)
  • 48.
    edited August 2012

    Allan wrote:

    Installing a git server seems redundant these days. We can create an azimuth account on github...

    Of course, just too busy to think. I'd be happy with github.

    Comment Source:Allan wrote: > Installing a git server seems redundant these days. We can create an azimuth account on github... Of course, just too busy to think. I'd be happy with github.
  • 49.
    edited August 2012

    Services:

    • upgraded snap-0.9.0.1 to snap-0.9.1.1
    • upgraded ghc-7.4.1 to ghc-7.4.2
    • the ISP has now opened ports 8000,8001,8002,8100,8101,8102 on the firewall
    • the azimuth server is currently serving (abs. no guarantees yet :() the Snap tutorial pages on stuttard.org.

    The system works by connecting a browser to the Apache httpd daemon process listening on standard http port 80 and instructions in an ~/public_html/.htaccess file redirect all requests from the browser to the azimuth server on port 8000.

    There are 3 servers running: ~/public_html/bin/azimuth on port 8000, ~/../../test on port 8001,, ~/../../dev on port 8100.

    To access them the syntax to type into the browser address bar will normally be:

    • stuttard.org/ for production servers
    • stuttard.org:8001 for servers under test
    • stuttard.org:8100 for servers being developed.

    Defects:

    • These have only been built today so they are strictly --alpha. Glyn and Allan might test them but others will have to bear with us until we have something demonstrably robust.
    • Snap depends on the Haskell Platform which, unlike Python or Ruby standard libraries, currently depends on OpenGL. Most low-cost shared ISPs don't run XWindows because of the bandwidth and maintenance requirements I guess and so don't have OpenGL installed. I've given up looking for a copy of intel GL/gl.h for the time being if not indefinitely. I had to build the needed components from the Haskell Platform by hand. Anybody who lurks around the Haskell community might help by registering (if it's working) from this Haskell Platform issues page and voting to remove the OpenGL dependency from the platform. Tnx.
    Comment Source:Services: * upgraded snap-0.9.0.1 to snap-0.9.1.1 * upgraded ghc-7.4.1 to ghc-7.4.2 * the ISP has now opened ports 8000,8001,8002,8100,8101,8102 on the firewall * the azimuth server is currently serving (abs. no guarantees yet :() the Snap tutorial pages on [stuttard.org](http://stuttard.org). The system works by connecting a browser to the Apache httpd daemon process listening on standard http port 80 and instructions in an ~/public_html/.htaccess file redirect all requests from the browser to the azimuth server on port 8000. There are 3 servers running: ~/public_html/bin/azimuth on port 8000, ~/../../test on port 8001,, ~/../../dev on port 8100. To access them the syntax to type into the browser address bar will normally be: * stuttard.org/ for production servers * stuttard.org:8001 for servers under test * stuttard.org:8100 for servers being developed. Defects: * These have only been built today so they are strictly --alpha. Glyn and Allan might test them but others will have to bear with us until we have something demonstrably robust. * Snap depends on the [Haskell Platform](http://haskellplatform.org) which, unlike Python or Ruby standard libraries, currently depends on OpenGL. Most low-cost shared ISPs don't run XWindows because of the bandwidth and maintenance requirements I guess and so don't have OpenGL installed. I've given up looking for a copy of intel GL/gl.h for the time being if not indefinitely. I had to build the needed components from the Haskell Platform by hand. Anybody who lurks around the Haskell community might help by registering (if it's working) from this Haskell Platform [issues page](http://trac.haskell.org/haskell-platform/ticket/57) and voting to remove the OpenGL dependency from the platform. Tnx.
  • 50.
    edited August 2012

    Admin:

    The ISP has helpfully answered a support ticket with the unix foo for detecting the server hardware uptime from which we can detect OS reboots (not quite right, but nearly).

    Admins can just type:

    uptime

    Which currently gives:

    0:45:48 up 13 days 2 users. load average 3.97, 4.94, 5.73

    Comment Source:Admin: The [ISP](http://bluehost.com) has helpfully answered a support ticket with the unix foo for detecting the server hardware uptime from which we can detect OS reboots (not quite right, but nearly). Admins can just type: > uptime Which currently gives: > 0:45:48 up 13 days 2 users. load average 3.97, 4.94, 5.73
Sign In or Register to comment.