I know absolutely nothing about F#. Let's see what I can make of it:
My guess is that the I after the number means integer. We are defining a function named factorial, which takes one argument, n, and if it is exactly 0, it returns 1, and if it is anything else, it recurses. I am not sure what the "rec" means, perhaps it tells the compiler that it is a recursive function? It is also unclear to me what is going to happen if you feed it a non-integer, or a negative integer.
As far as the python one-liner, I know python pretty well, but I have to think a bit to actually decipher what is it going to do. Does it mean
No, PDF format is a crippled postscript. It was intentionally crippled so it will NOT be a language, because distributing documents written in a programming language was not secure. Then they realized they crippled it too much, and added javascript to it. It is an improvement, since the scripts are localized in the document, easier to identify, they can be disabled if you want to, etc.
I think in general having scripting language embedded into an interactive document format is a good idea, however, it seems that Adobe's implementation is rather buggy and badly designed.
Yeah, but it is a lot of pain to do all that, and then someone opens it in a different spreadsheet program, and it will look like crap again. As someone above said, one should use the right tool for each job, and when designing a layout of a document and typesetting it, spreadsheet is not the tool.
If they were smart, they would treat it as a regular cell phone, and charge you a hefty monthly data fee for general internet access, while still keeping access to the B and N site free. And B and N would open an application store.
That's exactly my impression. Crossing from US to Canada was fine, crossing back very strongly reminded me of crossing from Poland to East Germany in mid 80's.
Ehm, it is my impression he says he has it working in FVWM, but cannot make it work in more modern desktop environments. Which does not surprise me. Every time I try to use some new window manager (usually because it comes as default after installing new system on a new computer, or because people rave about how great it is), I always end up returning back to FVWM, because nothing has the functionality of FVWM, while being equally fast and lightweight. Compiz is just beginning to implement things that FVWM had, well, you said it, over 15 years ago.
Please read his post again. He clearly states that his current window manager (FVWM) handles this fine, and he is wondering if more modern, more common window managers handle it too. Since I too am a FVWM user (quite satisfied, in fact the reason I always return to FVWM is that other window managers simply do not have the functionality and flexibility FVWM does), I can confirm that it is possible to do this in FVWM. I cannot provide any information about other WM, as I never used any of them with multiple monitors.
I've used KDE for years and it has very advanced keybinds to move windows pretty much anywhere. I can resize and move windows with just my keyboard. It has had this functionality much longer than windows ever had. Your only problem is the window manager. Linux isn't lacking in these power tools, you just aren't using them.
Well, if you want to argue which WM or platform had which functionality first, in FVWM you could move and resize windows with keyboard only (in fact, perform any WM action with keyboard only) long time before KDE development even started.
They are graphs scaled down so that they fit well wit the surrounding test. It's not actually completely simple. As far as I know, Tufte never claimed to invent them, he just described them in his book, and developed some theory on how sparklines should look like to work well. Possibly he also coined the term sparkline, I am not sure about that.
That's pretty interesting. If I remember correctly, there is a LaTeX package for creating sparklines, it uses data that can be embedded in the document, it takes additional parameters that influence the look of the sparkline, and if you change the data a re-run latex, the sparkline changes to reflect the new data, while preserving the look given by the additional parameters. Add to it a system that watches your file and rerun latex every time to see a change in order to generate a preview (I believe I have seen at least one such editor), and it seems to me exactly like what they are describing. I don't quite understand what they mean by "matrix of points proportional to the associated location in the document". If that is the only difference, it really seems too little to deserve a patent.
Actually, that's incorrect. GIMP was first made with Motif, and because of restrictions associated with Motif, the GIMP developers decided to create their own toolkit, GTK (aka the GIMP ToolKit). GIMP came first, GTK was later.
As far as GIMP interface goes, it seems to be rather fashionable to complain about it, but I don't think it is that terrible. One thing I would really like to have is a simple way to create a custom menu or toolbox with most frequently used tools and filters. If that was easy to do, I would have nothing whatsoever against GIMPs user interface. Of course, having 16 bit channels would be nice.
Hm, never happened to me. I have few hundreds pdf files here, many of them with 2 or 3 columns, tables, formulas etc, and I don't seem to have any problems with selecting text. What software were your pdf files generated by, anyway?
If you want to take advantage of the advanced PDF features like embedded javascript or forms that submit to the web, you're basically SOL without Acrobat
Actually, pdfTeX lets you do both of these quite easily, and I believe Scribus does, too. There are features of pdf that you do need Acrobat for, but the two you mentioned are not among them.
Hell, you can't even/select/ text normally using most PDF readers.
People keep saying that. I never had a problem with this. I use 3 or 4 different pdf readers, including the one from Adobe, and I never had problems with selecting and cutting text from a pdf document.
Either you provide data, or you provide a document. Extracting textual data from pdf is not any harder than extracting them from a word file or an odf document.
If you want to provide data, provide data, in a csv format of something simple like that.
In fact, with pdf, you can do both, since you can attach the cvs or whatever format data to the document.
If you are going to suggest presenting word document, then complaining about pdf not being open standard is somewhat hypocritical. The problem actually has nothing to do with openness of the pdf format, but rather with the fact that Adobe Reader is closed. Anybody is free to implement a reader that will allow to save filled in forms, and will allow commenting of pdf file, there is nothing in the format that could prevent it.
Also, creating pdf files from word documents is not the best way of doing it, in fact, I suspect that a lot of the bad rap that pdf gets is due to a huge amount of lousy pdf files created from word documents flooding the internet.
...but you can't defend yourself with a can of beans.
Take a tablet of Esbit solid fuel, or some similar such crap, two bricks or something, place the tablet between the bricks, light it and place the can unopened on top when you hear the zombies approaching. Take a good cover.
why no online version? probably because online document editing and storage is a horrible, horrible idea.
I don't think it is a horrible idea. I don't think it is a very new idea, either. I wrote my whole dissertation online, more than 10 years ago. It was very simple, all I needed to do was to hook up an old Informer terminal (my friend found it next to a garbage can at a hallway in a physics department building) into a modem, and I could edit my documents from the comfort of my own home, while all the heavy processing including producing the final postscript file was done on our department's mainframe. I did not have to install anything at home, all my software, backups etc was maintained by our department's wonderful team of sysadmins, so all I had to do is concentrate on the writing.
Look at something like LyX or Scientific Word. They are both frontends to LaTeX. There is no real reason why you should have to have TeX, with all of its packages, fonts etc installed on your local hard drive in order to use a frontend like that. Nor there is any reason why the conversion from the internal LyX file format into a final postscript or pdf document has to happen on your local cpu. Having a sort of thin frontend on your computer, which would work the same way LyX works now, except defer all the actual file management and processing to a remote server, would be perfectly enough for most purposes. And you could still get the actual LaTeX file from that if you wanted to do something special.
The mount could easily be swappable, too. Old Exacta cameras had swappable mounts. Of course there was no electronics involved, but you could fit pretty much any lense designed for a 35mm camera plus some more on an Exacta.
I know absolutely nothing about F#. Let's see what I can make of it:
My guess is that the I after the number means integer. We are defining a function named factorial, which takes one argument, n, and if it is exactly 0, it returns 1, and if it is anything else, it recurses. I am not sure what the "rec" means, perhaps it tells the compiler that it is a recursive function? It is also unclear to me what is going to happen if you feed it a non-integer, or a negative integer.
As far as the python one-liner, I know python pretty well, but I have to think a bit to actually decipher what is it going to do. Does it mean
(return 1) if n == 0 ... or return (1 if ...)?
No, PDF format is a crippled postscript. It was intentionally crippled so it will NOT be a language, because distributing documents written in a programming language was not secure. Then they realized they crippled it too much, and added javascript to it. It is an improvement, since the scripts are localized in the document, easier to identify, they can be disabled if you want to, etc.
I think in general having scripting language embedded into an interactive document format is a good idea, however, it seems that Adobe's implementation is rather buggy and badly designed.
Yeah, but it is a lot of pain to do all that, and then someone opens it in a different spreadsheet program, and it will look like crap again. As someone above said, one should use the right tool for each job, and when designing a layout of a document and typesetting it, spreadsheet is not the tool.
If they were smart, they would treat it as a regular cell phone, and charge you a hefty monthly data fee for general internet access, while still keeping access to the B and N site free. And B and N would open an application store.
That's exactly my impression. Crossing from US to Canada was fine, crossing back very strongly reminded me of crossing from Poland to East Germany in mid 80's.
Cats are conscious beings...
Live cats are.
Ehm, it is my impression he says he has it working in FVWM, but cannot make it work in more modern desktop environments. Which does not surprise me. Every time I try to use some new window manager (usually because it comes as default after installing new system on a new computer, or because people rave about how great it is), I always end up returning back to FVWM, because nothing has the functionality of FVWM, while being equally fast and lightweight. Compiz is just beginning to implement things that FVWM had, well, you said it, over 15 years ago.
Please read his post again. He clearly states that his current window manager (FVWM) handles this fine, and he is wondering if more modern, more common window managers handle it too. Since I too am a FVWM user (quite satisfied, in fact the reason I always return to FVWM is that other window managers simply do not have the functionality and flexibility FVWM does), I can confirm that it is possible to do this in FVWM. I cannot provide any information about other WM, as I never used any of them with multiple monitors.
I've used KDE for years and it has very advanced keybinds to move windows pretty much anywhere. I can resize and move windows with just my keyboard. It has had this functionality much longer than windows ever had. Your only problem is the window manager. Linux isn't lacking in these power tools, you just aren't using them.
Well, if you want to argue which WM or platform had which functionality first, in FVWM you could move and resize windows with keyboard only (in fact, perform any WM action with keyboard only) long time before KDE development even started.
Part of what they're trying to patent, is sizing an inline graphic to the same height as your font.
Which, if I understand it correctly, is exactly what the sparkline LaTeX package does. And, the package first appeared in 2004.
They are graphs scaled down so that they fit well wit the surrounding test. It's not actually completely simple. As far as I know, Tufte never claimed to invent them, he just described them in his book, and developed some theory on how sparklines should look like to work well. Possibly he also coined the term sparkline, I am not sure about that.
That's pretty interesting. If I remember correctly, there is a LaTeX package for creating sparklines, it uses data that can be embedded in the document, it takes additional parameters that influence the look of the sparkline, and if you change the data a re-run latex, the sparkline changes to reflect the new data, while preserving the look given by the additional parameters. Add to it a system that watches your file and rerun latex every time to see a change in order to generate a preview (I believe I have seen at least one such editor), and it seems to me exactly like what they are describing. I don't quite understand what they mean by "matrix of points proportional to the associated location in the document". If that is the only difference, it really seems too little to deserve a patent.
Actually, that's incorrect. GIMP was first made with Motif, and because of restrictions associated with Motif, the GIMP developers decided to create their own toolkit, GTK (aka the GIMP ToolKit). GIMP came first, GTK was later.
As far as GIMP interface goes, it seems to be rather fashionable to complain about it, but I don't think it is that terrible. One thing I would really like to have is a simple way to create a custom menu or toolbox with most frequently used tools and filters. If that was easy to do, I would have nothing whatsoever against GIMPs user interface. Of course, having 16 bit channels would be nice.
sudo mod me up
I would, if I had some. ROTFL!
Hm, never happened to me. I have few hundreds pdf files here, many of them with 2 or 3 columns, tables, formulas etc, and I don't seem to have any problems with selecting text. What software were your pdf files generated by, anyway?
If you want to take advantage of the advanced PDF features like embedded javascript or forms that submit to the web, you're basically SOL without Acrobat
Actually, pdfTeX lets you do both of these quite easily, and I believe Scribus does, too. There are features of pdf that you do need Acrobat for, but the two you mentioned are not among them.
Hell, you can't even /select/ text normally using most PDF readers.
People keep saying that. I never had a problem with this. I use 3 or 4 different pdf readers, including the one from Adobe, and I never had problems with selecting and cutting text from a pdf document.
Either you provide data, or you provide a document. Extracting textual data from pdf is not any harder than extracting them from a word file or an odf document.
If you want to provide data, provide data, in a csv format of something simple like that.
In fact, with pdf, you can do both, since you can attach the cvs or whatever format data to the document.
How many free programs do you know of that create .pdf's?
To lazy to count right now, but just what I use on more or less daily bases, about 20. Plus hundreds of others that I don't use.
If you are going to suggest presenting word document, then complaining about pdf not being open standard is somewhat hypocritical. The problem actually has nothing to do with openness of the pdf format, but rather with the fact that Adobe Reader is closed. Anybody is free to implement a reader that will allow to save filled in forms, and will allow commenting of pdf file, there is nothing in the format that could prevent it.
Also, creating pdf files from word documents is not the best way of doing it, in fact, I suspect that a lot of the bad rap that pdf gets is due to a huge amount of lousy pdf files created from word documents flooding the internet.
As well as phosphorus.
...but you can't defend yourself with a can of beans.
Take a tablet of Esbit solid fuel, or some similar such crap, two bricks or something, place the tablet between the bricks, light it and place the can unopened on top when you hear the zombies approaching. Take a good cover.
Yeah, maybe it's time to return to usenet.
And then you get eaten by a grue...
why no online version? probably because online document editing and storage is a horrible, horrible idea.
I don't think it is a horrible idea. I don't think it is a very new idea,
either. I wrote my whole dissertation online, more than 10 years ago. It was
very simple, all I needed to do was to hook up an old Informer terminal (my
friend found it next to a garbage can at a hallway in a physics department
building) into a modem, and I could edit my documents from the comfort of my
own home, while all the heavy processing including producing the final
postscript file was done on our department's mainframe. I did not have to
install anything at home, all my software, backups etc was maintained by our
department's wonderful team of sysadmins, so all I had to do is concentrate on
the writing.
Look at something like LyX or Scientific Word. They are both frontends to
LaTeX. There is no real reason why you should have to have TeX, with all of
its packages, fonts etc installed on your local hard drive in order to use a
frontend like that. Nor there is any reason why the conversion from the
internal LyX file format into a final postscript or pdf document has to happen
on your local cpu. Having a sort of thin frontend on your computer, which
would work the same way LyX works now, except defer all the actual file
management and processing to a remote server, would be perfectly enough for
most purposes. And you could still get the actual LaTeX file from that if you
wanted to do something special.
The mount could easily be swappable, too. Old Exacta cameras had swappable mounts. Of course there was no electronics involved, but you could fit pretty much any lense designed for a 35mm camera plus some more on an Exacta.