They're putting ads between letting you read articles and the like. It seems to happen randomly as far as I can tell and they're doing it on http://groups.yahoo.com/ too - that's where I first came across it. It's unpleasant to say the least, but not dishonest.
If you had problems with LyX, it's because you were treating it as a Word Processor, which it isn't. If it's counterintuitive, that's why. this comment explains things better than I could. The worst thing about LyX is that XForms is ugly and clunky, but you get over that.
Did you even think of reading the manuals? If I was using a program that uses a paradigm I wasn't used to, I'd read the manual. I mean, you wouldn't expect a functional language like O'Caml to work the same way as an imperitive language like C, would you? It's the same sort of thing, in a way.
You can't beat it, quite frankly. It does all the work for you and produces beautiful output with LaTeX.
I've struggled with Word to get its stylesheets to work as well, but I've never really got it to work in a manner I find satisfactory. It's just not easy enough to change between styles and it's not possible to do some of the tricks you can with TeX. I'm not talking anything hard here, I'm just talking about getting paragraphs formatted nicely i.e. No indentation on a leading paragraph and indentation on any following paragraphs. There are (IMO) nasty kludges you can use, but it just doesn't work as well.
I'm trundling through Children of Dune currently myself. Did the SciFi channel make a Dune Messiah mini-series? I just can't get the thought off of a naked teenage Alia exercising. What can I say, I'm letch;-)
Agreed. There are an immense number of ways the US voting system could be improved. FPTP is just a bad system. For the likes of presidential elections and congress elections, implementing a STV (Single Transferrable Vote) system would be a huge improvement. That way, those who wanted to vote for a candidate, yet protest dissatisfation with them in some way could give their first preference to a different candidate and their second to the candidate they wanted elected. A much better system.
To be honest, I've never had a problem with this kind of syntax. Then again, I tend to make my function names and variable names in any language look different. I've never quite understood why people use the same style for both...
I've never understood why he uses his own archive format. Hrmph! Anyway, I downloaded !Creator, !Translator and !GreyEdit. The !Creator and !Translator archives seem to be corrupt, bombing out as soon as !PackDir gets as far as the bin directory.
I won't be able to contact him by email so if somebody else would, I'd be grateful.
Please, the lameness filter must die! I'm submitting this so that any site hosting
it doesn't get slashdotted.
The format of a Sprite file (or area) is as follows:
l Control l Extn l l l l l Free l
l Block l area l Sprite l Sprite l l Sprite l space l
l l (opt) l l l l l l
There are two slight variations on the above arrangement:
When saved as a file
When stored in memory for use with the Sprite rendering and handling module (in which case it is known as a sprite area)
When in memory, the sprite area has an extra word at the start of the control block, and also may have the free space that sprite files don not have. The free space is used when preforming operations that add or extend the sprites in the area.
The format of the Control Block is as follows (remember multibyte values are little-endian):
Offset Size Description
0 4 Byte offset to last byte + 1 (ie total size of
sprite area, including free space)
4 4 Number of sprites in area
8 4 Byte offset to first sprite
12 4 Byte offset to first free word (ie byte after
last sprite)
16 n Extension words (usually none)
For sprite files the first word is not included, but all offsets are set as if it was still there (ie when examining the file, all offsets appear to be 4 bytes too large).
Also when saved as a file, the word at offset 12, should be set to point to the byte after the last sprite (ie the 'free space' should be removed).
Format of a sprite
The format of each sprite in the sprite area/file is as follows:
l Sprite l Palette l Sprite l Plotting l
l Control l area l image l mask l
l Block l (opt) l l (opt) l
The Sprite Control Block contains the following:
(Note sprite offsets are from the beginning of the sprite)
Offset Size Description
0 4 Offset to next sprite (from here)
4 12 Sprite name (up to 12 characters with trailing zeroes)
16 4 Width in words - 1
20 4 Height in scan lines
24 4 First bit used (left end of row)
28 4 Last bit used (right end of row)
32 4 Offset to sprite image
36 4 Offset to transparency mask (or sprite image if
there is no mask)
40 4 Screen mode sprite was defined in
44 n Palette data (optional)
The Palette
The size of the palette data block depends on the number of bits per pixel in the sprites mode, since there will be one entry for each potential logical colour.
Each palette entry is two words long:
Offset Size Description
0 4 First colour of flashing pair
4 4 Second colour of flashing pair
Note: although flashing colours are still supported, it is very rare to find flashing palettes in sprites nowadays.
Each palette value is of the form:
Bits Meaning
0 - 7
8 - 15 Amount of red
16 - 23 Amount of green
24 - 31 Amount of blue
Yeah, but it'd be nice if they all contributed to keeping the kernel unified rather than making that specialised. Where they can co-operate on stuff, they should rather than duplicating each other's effort needlessly. That's my opinion anyway, but I can see and respect where you're coming from.
It's close to idiot-proof, but they really need to fix the dependencies between the various RPMs they supply. The reason why apt is so great is the Debian guys put some time into making sure the dependencies between the various packages.
Then there's the matter of omitting major packages from their hierarchial view. I had to go into the list view to find KDevelop nestled snugly amongst all the other unlisted packages. Why weren't they in the hierarchial view?
I'm not asking that they jump to any assumptions, I'm just saying that they should employ a little more conservatism in selecting which packages are required in the various groups and should fix the package dependancies. I'd swear the dependancy counting is flawed in their package management tools.
And another thing, when you're uninstalling a package, it shouldn't force you to uninstall any related packages. Rather, if any related packages aren't depended upon after selecting a given package for uninstallation, it should offer you the choice of selecting those you want to remain on you system. Just because you want to uninstall AbiWord doesn't mean it should uninstall GNOME.
Now, I was sort of spoiled because I started coding BBC BASIC V as shipped with RISC OS rather than the earlier dialect shipped with the BBC. I had Zap (a text editor modelled on Emacs but much smaller and simpler in a good way) which is a great BASIC development environment, especially in ARMBE emulation mode.
As far as pointers go, integers were pointers. If you wanted to read a NULL-terminated string at the location pointed to by the variable blk%, you'd use $blk%. To read a 32-bit integer, you'd use !blk%. To read a byte, you'd use ?blk%. There are quite a few things about doing things this way that are easier than the C-style scheme and in part manage to nullify some of the need for structures.
As far as error detection goes, at the top of any non-multitasking programs I had, I'd always have this line:
ON ERROR ON ERROR OFF:MODE 0:PRINT REPORT$;" at "; ERL:END
And that'd do the trick. Most of the time I'd do something more complicated like jump to a shutdown procedure, but that'd be the basic scheme.
Keyword highlighting is all down to the editor you use. Sure, Emacs does it, but does pico? It helps, and in fairness Zap did keyword highlighting but I wasn't ever dependant on it. That doesn't really have anything to do with BASIC though.
If I'm playing with a BBC, I'll throw it into mode 0 ('cause mode 7 is teletext mode and it hurts my eyes) and code away, no problem.
Still, you have to admit that any BASIC interpreter that had a built in assembler was definitely funky. AFAIK, all development for Elite was done using the interpreter.
I'm not sure... The machine's a laptop (laptop = hard to upgrade, no second harddrive) already dualboots W2K and Linux. It was hard enough to get W2K to accept that it was running alongside another OS in the first place.
I've reinstalled Mandrake thrice and no matter what I do, unless I've selected the packages myself very carefully, Mandrake will always install a bunch of extra crud too, stuff that really didn't make sense. It also tried uninstalling stuff that I very much didn't want uninstalled when I tried using their package manager. Pity.
Um, other stuff: has anybody else had speed problems running OpenGL games on Mandrake 8.0 on Dell Latitude laptops like me?
Apparently, the bit about the TCP/IP stack is true. I intend on checking it out some time, but supposedly it's a lump of cruft. Not exactly as cleanly coded as the BSD one nor as efficient.
Slashdot Mirror
Is that a bad thing? Classes that use multiple inheritence can easily be a pain to maintain.
...but there's people out there who design languages for fun, you know. Take a look at the languages on the esoteric programming languages ring or maybe even subscribe to the mailing list, but only if it all interests you.
They're putting ads between letting you read articles and the like. It seems to happen randomly as far as I can tell and they're doing it on http://groups.yahoo.com/ too - that's where I first came across it. It's unpleasant to say the least, but not dishonest.
Did you even think of reading the manuals? If I was using a program that uses a paradigm I wasn't used to, I'd read the manual. I mean, you wouldn't expect a functional language like O'Caml to work the same way as an imperitive language like C, would you? It's the same sort of thing, in a way.
Gee, being a Roman Catholic (and Irish at that) I'd almost rate this one as funny, considering my background.
You can't beat it, quite frankly. It does all the work for you and produces beautiful output with LaTeX.
I've struggled with Word to get its stylesheets to work as well, but I've never really got it to work in a manner I find satisfactory. It's just not easy enough to change between styles and it's not possible to do some of the tricks you can with TeX. I'm not talking anything hard here, I'm just talking about getting paragraphs formatted nicely i.e. No indentation on a leading paragraph and indentation on any following paragraphs. There are (IMO) nasty kludges you can use, but it just doesn't work as well.
You never read the Dune Series and the works of Frederich Nietzsche, did you?
"Too many cooks spoil the broth" vs. "Many hands make light work"
Contradiction, but there's truth in both.
That isn't what I heard. It uses a Nintendo custom chip to provide sound. It's not exactly a SID, but it does the job.
I'm trundling through Children of Dune currently myself. Did the SciFi channel make a Dune Messiah mini-series? I just can't get the thought off of a naked teenage Alia exercising. What can I say, I'm letch ;-)
The ARM is fast enough to emulate a Gameboy itself. I'm surprised they'd go and use a more expensive hardware solution to maintain compatibility.
Try reading Dune Messiah. In that, Chani gave birth to two children: a daughter, Ghanima, and another son, also called Leto.
Agreed. There are an immense number of ways the US voting system could be improved. FPTP is just a bad system. For the likes of presidential elections and congress elections, implementing a STV (Single Transferrable Vote) system would be a huge improvement. That way, those who wanted to vote for a candidate, yet protest dissatisfation with them in some way could give their first preference to a different candidate and their second to the candidate they wanted elected. A much better system.
To be honest, I've never had a problem with this kind of syntax. Then again, I tend to make my function names and variable names in any language look different. I've never quite understood why people use the same style for both...
Uh-hu! Look at this message I posted further up in the thread.
Well, I still have my A3010 and I have it here in the flat. I'll take a look. I can't remember Clear files supporting transparency at all...
s /l ocal/riscos/converters/translator.arc/%21Translatr /Docs/Guide?extract=true
...a while later...
Well, I took a look at the manual for !Translator 7.21 (08 Aug 1993) and it made no mention of masks of any type. I looked this up at:
http://www.mirror.ac.uk/collections/hensa-micro
...a while later...
I've never understood why he uses his own archive format. Hrmph! Anyway, I downloaded !Creator, !Translator and !GreyEdit. The !Creator and !Translator archives seem to be corrupt, bombing out as soon as !PackDir gets as far as the bin directory.
I won't be able to contact him by email so if somebody else would, I'd be grateful.
Unless I'm completely wrong, the only way you can do masking with GIFs is by selecting a colour in the palette as the mask.
Please, the lameness filter must die! I'm submitting this so that any site hosting
it doesn't get slashdotted.
The format of a Sprite file (or area) is as follows:
l Control l Extn l l l l l Free l
l Block l area l Sprite l Sprite l l Sprite l space l
l l (opt) l l l l l l
There are two slight variations on the above arrangement:
When saved as a file
When stored in memory for use with the Sprite rendering and handling module (in which case it is known as a sprite area)
When in memory, the sprite area has an extra word at the start of the control block, and also may have the free space that sprite files don not have. The free space is used when preforming operations that add or extend the sprites in the area.
The format of the Control Block is as follows (remember multibyte values are little-endian):
Offset Size Description
0 4 Byte offset to last byte + 1 (ie total size of
sprite area, including free space)
4 4 Number of sprites in area
8 4 Byte offset to first sprite
12 4 Byte offset to first free word (ie byte after
last sprite)
16 n Extension words (usually none)
For sprite files the first word is not included, but all offsets are set as if it was still there (ie when examining the file, all offsets appear to be 4 bytes too large).
Also when saved as a file, the word at offset 12, should be set to point to the byte after the last sprite (ie the 'free space' should be removed).
Format of a sprite
The format of each sprite in the sprite area/file is as follows:
l Sprite l Palette l Sprite l Plotting l
l Control l area l image l mask l
l Block l (opt) l l (opt) l
The Sprite Control Block contains the following:
(Note sprite offsets are from the beginning of the sprite)
Offset Size Description
0 4 Offset to next sprite (from here)
4 12 Sprite name (up to 12 characters with trailing zeroes)
16 4 Width in words - 1
20 4 Height in scan lines
24 4 First bit used (left end of row)
28 4 Last bit used (right end of row)
32 4 Offset to sprite image
36 4 Offset to transparency mask (or sprite image if
there is no mask)
40 4 Screen mode sprite was defined in
44 n Palette data (optional)
The Palette
The size of the palette data block depends on the number of bits per pixel in the sprites mode, since there will be one entry for each potential logical colour.
Each palette entry is two words long:
Offset Size Description
0 4 First colour of flashing pair
4 4 Second colour of flashing pair
Note: although flashing colours are still supported, it is very rare to find flashing palettes in sprites nowadays.
Each palette value is of the form:
Bits Meaning
0 - 7
8 - 15 Amount of red
16 - 23 Amount of green
24 - 31 Amount of blue
Yeah, but it'd be nice if they all contributed to keeping the kernel unified rather than making that specialised. Where they can co-operate on stuff, they should rather than duplicating each other's effort needlessly. That's my opinion anyway, but I can see and respect where you're coming from.
;-)
Official? Pffftt! Choice is good
Aw, c'mon! I'm talking about forks in the kernel, not producing variations upon it. The kernel, and this is my opinion ok, is what makes the OS.
It's close to idiot-proof, but they really need to fix the dependencies between the various RPMs they supply. The reason why apt is so great is the Debian guys put some time into making sure the dependencies between the various packages.
Then there's the matter of omitting major packages from their hierarchial view. I had to go into the list view to find KDevelop nestled snugly amongst all the other unlisted packages. Why weren't they in the hierarchial view?
I'm not asking that they jump to any assumptions, I'm just saying that they should employ a little more conservatism in selecting which packages are required in the various groups and should fix the package dependancies. I'd swear the dependancy counting is flawed in their package management tools.
And another thing, when you're uninstalling a package, it shouldn't force you to uninstall any related packages. Rather, if any related packages aren't depended upon after selecting a given package for uninstallation, it should offer you the choice of selecting those you want to remain on you system. Just because you want to uninstall AbiWord doesn't mean it should uninstall GNOME.
Rant, rant, rant, rant, rant...
My big problem though is repartitioning the damned thing. It's just an awful pain.
I use GRUB myself.
Now, I was sort of spoiled because I started coding BBC BASIC V as shipped with RISC OS rather than the earlier dialect shipped with the BBC. I had Zap (a text editor modelled on Emacs but much smaller and simpler in a good way) which is a great BASIC development environment, especially in ARMBE emulation mode.
As far as pointers go, integers were pointers. If you wanted to read a NULL-terminated string at the location pointed to by the variable blk%, you'd use $blk%. To read a 32-bit integer, you'd use !blk%. To read a byte, you'd use ?blk%. There are quite a few things about doing things this way that are easier than the C-style scheme and in part manage to nullify some of the need for structures.
As far as error detection goes, at the top of any non-multitasking programs I had, I'd always have this line:
ON ERROR ON ERROR OFF:MODE 0:PRINT REPORT$;" at "; ERL:END
And that'd do the trick. Most of the time I'd do something more complicated like jump to a shutdown procedure, but that'd be the basic scheme.
Keyword highlighting is all down to the editor you use. Sure, Emacs does it, but does pico? It helps, and in fairness Zap did keyword highlighting but I wasn't ever dependant on it. That doesn't really have anything to do with BASIC though.
If I'm playing with a BBC, I'll throw it into mode 0 ('cause mode 7 is teletext mode and it hurts my eyes) and code away, no problem.
Still, you have to admit that any BASIC interpreter that had a built in assembler was definitely funky. AFAIK, all development for Elite was done using the interpreter.
I'm not sure... The machine's a laptop (laptop = hard to upgrade, no second harddrive) already dualboots W2K and Linux. It was hard enough to get W2K to accept that it was running alongside another OS in the first place.
Maybe when I get a new machine.
I've reinstalled Mandrake thrice and no matter what I do, unless I've selected the packages myself very carefully, Mandrake will always install a bunch of extra crud too, stuff that really didn't make sense. It also tried uninstalling stuff that I very much didn't want uninstalled when I tried using their package manager. Pity.
Um, other stuff: has anybody else had speed problems running OpenGL games on Mandrake 8.0 on Dell Latitude laptops like me?
Another thing: will FreeDOS run Dune ok?
Apparently, the bit about the TCP/IP stack is true. I intend on checking it out some time, but supposedly it's a lump of cruft. Not exactly as cleanly coded as the BSD one nor as efficient.
Please refute this, somebody.