Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On 22/10/2011, Patrick Haller 201009-suckl...@haller.ws wrote: Hickey kicks unix because although pipes = composability, output and input = free-form text. We combined data exchange with user interface, and user interface usually won that fight. Say data exchange won; would it help us to rewrite our programs to output JSON and our shells to pretty-print* JSON? You pretty much just described TermKit [1]. I think there is something wrong with the shell paradigm, but I'm not convinced JSON-structured IO is the right approach. My suggestion in the earlier mailing list discussion was to allow programs to draw directly to the terminal, in little Xembedded frames, but of course that change only improves the interface: to avoid let's all write parsers you'd also have to come up with some kind of typing system like TermKit's MIME headers. Also, the representation of data would be a concern of each program, not of the terminal, which would probably result in ugly. So I think the necessary next step would be to have a strongly typed shell. To pretty-print you'd need to add a polymorphic à la carte (multiple dispatch) pretty-printing function for the given data type. The type inference would be done per command, so cat(1) would be of a type such that if you were to try catting an image (directly) to wc(1) it would fail, because the types (Image, String) would not match. You could also have awesome higher-order functions, so 'map' would remove the need for find(1), etc. I know, Unix purists will rage about this added complexity. And it's true, it would be rather more complex. But in my opinion we ought to optimise for effectiveness of use by the user, not efficiency of execution by the machine: we should look at where we want to go and determine the simplest way of getting there, not succumb to nihilism because it's simpler to stay where we are. But I suspect this approach is too Haskell-like for most people here... [1]: http://acko.net/blog/on-termkit cls
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
b...@methodlogic.net a écrit : Is there a downloadable version of this, or something that I can point mplayer to? Flashplayer == fail for me. rtmpdump -r 'rtmpe://video.infoq.com/cfx/st/presentations/11-sep-simplemadeeasy.mp4' -o simple_made_easy.mp4
Re: [dev] Introducing XLSH
well I had a lot of fun coding it and it works for me do we have a fortunes file?
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
Connor Lane Smith c...@lubutu.com once said: So I think the necessary next step would be to have a strongly typed shell. To pretty-print you'd need to add a polymorphic à la carte (multiple dispatch) pretty-printing function for the given data type. The type inference would be done per command, so cat(1) would be of a type such that if you were to try catting an image (directly) to wc(1) it would fail, because the types (Image, String) would not match. You could also have awesome higher-order functions, so 'map' would remove the need for find(1), etc. Then someone will ask for sub-typing and someone else will want ADTs and we'll wake up one day and have to learn category theory just to use a shell. :) A while ago I thought about doing something similar in a more general way. Say we modified the Plan 9 pipe(2) system call to check the current process's namespace for /dev/pipe instead of using the hard- coded pipe(3) device. This would allow us to build custom type-safe pipes as user-space filesystems. You could then do something like: % jsonpipefs -m /mnt/json % ls /mnt/json data data1 % bind /mnt/json /dev/pipe % produce | consume # these commands expect a serialized JSON stream The beauty of this is that the stream typing logic is separated from individual programs and, of course, the shell. Cheers, Anthony
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
rtmpdump -r 'rtmpe://video.infoq.com/cfx/st/presentations/11-sep-simplemadeeasy.mp4' -o simple_made_easy.mp4 Thanks, now I don't have to restart my web browser, but compiling still sucks on this machine. Is there still no cloud service taking random URLs and bringing you download links to all embedded media?
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On Sat, Oct 22, 2011 at 12:12:09PM +0200, hiro wrote: rtmpdump -r 'rtmpe://video.infoq.com/cfx/st/presentations/11-sep-simplemadeeasy.mp4' -o simple_made_easy.mp4 thanks too. Thanks, now I don't have to restart my web browser, but compiling still sucks on this machine. Is there still no cloud service taking random URLs and bringing you download links to all embedded media? What's suckless about software as a service? v4hn pgpcmESQVwtYZ.pgp Description: PGP signature
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
What's suckless about software as a service? useful services? Sorry if I'm not using these buzzwords ansi conform. suckless people suck more and more.
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On Sat, Oct 22, 2011 at 01:07:38PM +0200, hiro wrote: What's suckless about software as a service? useful services? Sorry if I'm not using these buzzwords ansi conform. At least I wouldn't call software/services which depend on the availability of one IP/Domain on the internet suckless! If you do, then I agree with you in the following... suckless people suck more and more. v4hn pgpIb5ZZ5smEV.pgp Description: PGP signature
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
Greetings. Connor Lane Smith wrote: On 22/10/2011, Patrick Haller 201009-suckl...@haller.ws wrote: Hickey kicks unix because although pipes = composability, output and input = free-form text. We combined data exchange with user interface, and user interface usually won that fight. Say data exchange won; would it help us to rewrite our programs to output JSON and our shells to pretty-print* JSON? You pretty much just described TermKit [1]. I think there is something wrong with the shell paradigm, but I'm not convinced JSON-structured IO is the right approach. My suggestion in the earlier mailing list discussion was to allow programs to draw directly to the terminal, in little Xembedded frames, but of course that change only improves the interface: to avoid let's all write parsers you'd also have to come up with some kind of typing system like TermKit's MIME headers. Also, the representation of data would be a concern of each program, not of the terminal, which would probably result in ugly. There were escape codes that allowed drawing basic things in a terminal. Another example how to do it is w3m[0], but this requires too much legacy code. It's still less than having more than one parser and a whole VM for the description lang- uage, like the web would require. Sincerely, Christoph Lohmann [0] http://w3m.cvs.sourceforge.net/viewvc/w3m/w3m/w3mimg/
Re: [dev] Introducing XLSH
2011/10/21 Michał Siejak mic...@siejak.pl: Back to the topic: xlsh github page now has proper wiki with HOWTOs on compiling and installing it on Arch and Ubuntu Linux as well as configuration articles. Head to: https://github.com/Nadrin/xlsh/wiki Thanks for writing this, Michał. Some reports on getting it working on Debian. In order to start it as your X display manager you need the following line in your /etc/inittab: x:2:respawn:/usr/local/sbin/xlshd -f Similar to arch, but different runlevel. Since the xdotool in debian/wheezy does not support the --sync option to the search command, I had to apply the hack in attached diff to give the xterm window focus. I'm sure there are better ways, it it seems to work. Also, xlsh fails to set my PATH to what's in include/config.h, but rather leaves it as /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin as specified in xlshrc. I don't know why. -- Mikael Schönenberg diff --git a/etc/xlshrc b/etc/xlshrc index ca9fbba..e1df4f4 100644 --- a/etc/xlshrc +++ b/etc/xlshrc @@ -19,7 +19,7 @@ fi xrdb -merge $XRESFILE xsetroot -solid $BGCOLOR if which xdotool; then - ( xwindow=$(xdotool search --sync --class $TERMINAL) -xdotool windowfocus $xwindow ) + ( xwindow=$(sleep 1 xdotool search --class $TERMINAL) +xdotool windowfocus --sync $xwindow ) fi exec $TERMINAL -g 80x15+$px+$py -e $(which xlsh)
[dev] Introducing SEE, the Simple Executing Engine
Hello all, I have subscribed this mail list for long time, but it is my first post here. I would like to introduce SEE, which is a very small script engine for embedded environment. It has the following advantages: - Hackable: the code base is small and the API is simple. - Portable: the dependency is clean (You may even port it to a naked environment like a OS kernel). the code is full written in C. - Full functionality: the language model is single-threaded, but concurrency can be implemented by external calls. And external calls are the only I/Os in the language (no standard I/O routines here). A simple garbage collector is implemented in SEE. For myself, I already used SEE in my toy game engine muGE. I hope SEE would be useful for you guys to enhance the functionality of your softwares. The copyright of SEE is dedicated to the public domain. SEE is hosted on github, http://github.com/xinhaoyuan/see
Re: [dev] Introducing SEE, the Simple Executing Engine
On 22.10.2011 15:47, Xinhao.Yuan wrote: http://github.com/xinhaoyuan/see Looks interesting, but what the hell is that? static char __sa[sizeof(gc_header_s) == GC_HEADER_SPACE ? 0 : -1];
Re: [dev] Introducing SEE, the Simple Executing Engine
On 22 October 2011 19:36, Pierre Chapuis catw...@archlinux.us wrote: On 22.10.2011 15:47, Xinhao.Yuan wrote: http://github.com/xinhaoyuan/see Looks interesting, but what the hell is that? static char __sa[sizeof(gc_header_s) == GC_HEADER_SPACE ? 0 : -1]; It's a similar compile time check similar to what dwm uses, in this case, it checks if gc_header_s is the same size as GC_HEADER_SPACE. Rob
