Re: [9fans] anyone put their venti on an SSD?
On Fri May 3 23:27:40 EDT 2013, sstall...@gmail.com wrote: > I had originally used a Crucial 32GB SSD years ago and swapped to a 55GB > OCZ enterprise drive (using sdahci). More recently I've moved my venti > arenas over to plan9port and have switched over to using the entire SSD for > fossil. So far this has been faster than running venti natively - though I > still take a replica each night out of paranoia. there are many components to the performance here, but i can think of at least one simple issue. plan 9 loopback tcp can be pretty slow due to scheduling issues. (induced by the structure of tcp, not any issue with the scheduler.) my atom (which is slightly worse than a d525) gets ladd; nettest -l -n 1 tcp!192.168.0.136!39769 count 1; 8192 bytes in 2.649575 s @ 29.5 MB/s (0ms) so i would imagine that working out how to post a fd to srv would really help a lot. not to mention, taking some funk out of configuring the network on boot. :-) - erik
Re: [9fans] anyone put their venti on an SSD?
> > I had similar problems with OCZ. > > I ought to have observed that I bought the drive from Fry's as refurbished, > which probably wasn't a good recommendation for a drive that was fairly new. Three strikes. Fate couldn't resist.
Re: [9fans] anyone put their venti on an SSD?
On Sat May 4 00:18:46 EDT 2013, cinap_len...@gmx.de wrote: > cwfs copies the blocks from worm into the cache on read. > so the working set is served from the ssd and the ram > buffer cache. reading /n/dump would hit the mechanical > disk tho. that's an option for ken's fs. i haven't found that it's fast enough because the latency to retrieve a block that's not in the cache is the latency for read(worm)+read(cachebkt)+ write(cache). if one keeps the cache small, the read of the cachebkt goes away. therefore it's best to keep cachesize << wormsize. - erik
Re: [9fans] anyone put their venti on an SSD?
On 4 May 2013 00:59, Charles Forsyth wrote: > I had similar problems with OCZ. I ought to have observed that I bought the drive from Fry's as refurbished, which probably wasn't a good recommendation for a drive that was fairly new.
Re: [9fans] anyone put their venti on an SSD?
no cats in picture! -- cinap
Re: [9fans] anyone put their venti on an SSD?
cwfs copies the blocks from worm into the cache on read. so the working set is served from the ssd and the ram buffer cache. reading /n/dump would hit the mechanical disk tho. -- cinap
Re: [9fans] anyone put their venti on an SSD?
I had originally used a Crucial 32GB SSD years ago and swapped to a 55GB OCZ enterprise drive (using sdahci). More recently I've moved my venti arenas over to plan9port and have switched over to using the entire SSD for fossil. So far this has been faster than running venti natively - though I still take a replica each night out of paranoia. On Fri, May 3, 2013 at 7:19 AM, Steve Simon wrote: > what the subject says, anyone put their venti (those that use it) > on a solid state disk? > > -Steve > >
Re: [9fans] anyone put their venti on an SSD?
> > well clearly, we must lump everything > > that breaks "anecdotally as often" > > in the same catagory, > > by manufacturer. > > > > - erik > > > > that was the worst haiku I've ever seen oh, now. you give me too much credit. i wasn't even trying. - erik
Re: [9fans] anyone put their venti on an SSD?
On Fri, May 03, 2013 at 10:00:41PM -0400, erik quanstrom wrote: > > On 2013-05-03, at 6:51 PM, erik quanstrom wrote: > > > > > imho, applying 50 years of experience with spinning hard drives with > > > the relatively new flash memory drive is a suspect comparison. > > > > Is it? Cheap SSD seems to break as often as cheap spinny disks. According > > to everyone's anecdotal stories, at least > > well clearly, we must lump everything > that breaks "anecdotally as often" > in the same catagory, > by manufacturer. > > - erik > that was the worst haiku I've ever seen
Re: [9fans] anyone put their venti on an SSD?
On 2013-05-03, at 7:00 PM, erik quanstrom wrote: > well clearly, we must lump everything > that breaks "anecdotally as often" > in the same catagory, > by manufacturer. Exactly. That's where we started this conversation :-)
Re: [9fans] anyone put their venti on an SSD?
> On 2013-05-03, at 6:51 PM, erik quanstrom wrote: > > > imho, applying 50 years of experience with spinning hard drives with > > the relatively new flash memory drive is a suspect comparison. > > Is it? Cheap SSD seems to break as often as cheap spinny disks. According > to everyone's anecdotal stories, at least well clearly, we must lump everything that breaks "anecdotally as often" in the same catagory, by manufacturer. - erik
Re: [9fans] anyone put their venti on an SSD?
On Fri May 3 17:59:27 EDT 2013, cinap_len...@gmx.de wrote: > i have 60GB intel ssd in my new fileserver holding the > cwfs worm cache. no problems so far. but the machine is > just up for two weeks. as long as we're straying from venti, i'll say that i've used ssds in ken's file server as both cache and worm drives. there were no problems at all. i've mostly used various intel drives, which have performed in accordance to all published specs. i've also used ocz drives as boot drives to hold nvram. no problems. perhaps this is the proverbial faint praise. on the subject of ken's file server / cwfs, it makes the most sense to me to use ssds as worm, not cache. bandwith to the cache isn't important as long as you don't blow the ram cache. but anything that isn't in the ram cache but is on the worm tends to be randomish access. ssds to very well at at random access, and write once decreases pressure on many things that make implementing a flash drive hard. i would expect similar from venti, which has an even more random data access pattern. - erik
Re: [9fans] anyone put their venti on an SSD?
On 2013-05-03, at 6:51 PM, erik quanstrom wrote: > imho, applying 50 years of experience with spinning hard drives with > the relatively new flash memory drive is a suspect comparison. Is it? Cheap SSD seems to break as often as cheap spinny disks. According to everyone's anecdotal stories, at least.
Re: [9fans] anyone put their venti on an SSD?
> Disk drive reliability comes and goes with the seasons. For years I > only ran Seagate disks, and wouldn't go near WD. Then, after a 30% > failure run on < 1 year old Seagates, I switched back to WDs, which > have been flawless for me. So far. And Hitachi has drifted in and > out of the picture over the years. imho, applying 50 years of experience with spinning hard drives with the relatively new flash memory drive is a suspect comparison. - erik
Re: [9fans] anyone put their venti on an SSD?
On 2013-05-03, at 6:43 PM, erik quanstrom wrote: > (i'm not absolving the drive. just saying that there are plan 9 > issues affecting your machine.) No doubt. But I got it to the point where it's working quite happily. And it can maintain that steady state until it tips over and dies, at which point I will re-install on much more current kit. I'm getting too old to fight with the hardware any more ;-P
Re: [9fans] anyone put their venti on an SSD?
On 2013-05-03, at 6:31 PM, cinap_len...@gmx.de wrote: > ocz seems to have a bad reputation. just googled "intel ssd broken" > and you get tons of results from people with broken/dead ocz ssd's. Disk drive reliability comes and goes with the seasons. For years I only ran Seagate disks, and wouldn't go near WD. Then, after a 30% failure run on < 1 year old Seagates, I switched back to WDs, which have been flawless for me. So far. And Hitachi has drifted in and out of the picture over the years. Ask anyone else and they will tell you a partially to completely different story. At $80 for a couple of TB, I'll just toss them out when they break. And while SSD isn't anywhere near that inexpensive yet, it's finally down into the price range where you can call it commodity disk. These days I'm paying a bit under $1/GB for SSD. That's cheap enough that I can afford to experiment with smaller sized drives in non-critical applications. I have a FreeBSD box that's been running off an OCZ Vertex 3 for a few months now without issue. It does regular buildworlds and the like, so I'm not gentle on the write volume. UFS TRIM support seems to work fine, and if you chose to believe the smart stats, the (128 GB) disk is error free after having many TB written to it. Many claim Sandforce disks will blow up well before this. I'm beginning to think otherwise, although my sample space is not statistically significant. I have a pair of Vertex 4s I haven't installed yet. I'm curious to see how much (or if) the new OCZ controllers work. The benchmarks I've read are impressive. I'm planning to put one into my Mac Mini. If MacOS and its several hundred GB VM footprint can't kill an SSD, nothing will ;-) --lyndon
Re: [9fans] anyone put their venti on an SSD?
> I was running a really bastardized mix of old and new boot software, > so it's quite possible I screwed up installing the correct MBR and > boot loader. But it might also have been a problem with the BIOS or > SATA controller on the motherboard -- it's a slightly ancient > Supermicro Atom 1U, and it doesn't like SATA hard disks, either (it's > currently talking to an IDE disk). I didn't have time to try 9atom. that sort of machine is 9atom's original raison d'être. also there were some issues with ide in pio mode recently fixed. (credit: stallion) you may still want to look at 9atom even in ide mode. (i'm not absolving the drive. just saying that there are plan 9 issues affecting your machine.) - erik
Re: [9fans] anyone put their venti on an SSD?
We've had a lot of success with Intel SSDs, only problem is that they seem to be in short supply right now. We're also looking at Samsung SSDs, and they seem to be perhaps even better than the Intel SSDs. OCZs break often in my experience. 2013/5/3 : > ocz seems to have a bad reputation. just googled "intel ssd broken" > and you get tons of results from people with broken/dead ocz ssd's. > > -- > cinap >
Re: [9fans] anyone put their venti on an SSD?
ocz seems to have a bad reputation. just googled "intel ssd broken" and you get tons of results from people with broken/dead ocz ssd's. -- cinap
Re: [9fans] anyone put their venti on an SSD?
On 2013-05-03, at 1:59 PM, ge...@plan9.bell-labs.com wrote: > I tried putting our index on a single OCZ SSD and it died during buildindex. > The SSD was completely unresponsive thereafter, which is pretty > appalling behaviour for a storage device. Having since sworn off > OCZ, I would try again with a pair of Intel 330s in a RAID. A couple of months ago I tried cloning my existing fossil+venti to an OCZ Vertex 3. I did the partitioning and setup by hand and everything seemed to go just fine: the arenas copied and verified, fossil initialized, and I could run and mount the fossil from the SSD, but whenever I tried to boot from it it failed very early on with "I/O error" and that was that. I didn't have any spare time to mess around with it so I just stuck with the existing disk. I was running a really bastardized mix of old and new boot software, so it's quite possible I screwed up installing the correct MBR and boot loader. But it might also have been a problem with the BIOS or SATA controller on the motherboard -- it's a slightly ancient Supermicro Atom 1U, and it doesn't like SATA hard disks, either (it's currently talking to an IDE disk). I didn't have time to try 9atom. That said, the limited testing I did with the secondary fossil+venti showed it to be quite zippy, within the limitations of the surrounding motherboard hardware. Certainly it was noticeably faster than the hard disk for, e.g., mk all. --lyndon
Re: [9fans] anyone put their venti on an SSD?
On 3 May 2013 21:59, wrote: > I tried putting our index on a single OCZ SSD and it died during > buildindex. > The SSD was completely unresponsive thereafter, which is pretty > appalling behaviour for a storage device. > I had similar problems with OCZ. I was only copying venti state (as raw partitions) from one drive to the ssd. I haven't tried again with other makes, mainly for lack of time.
Re: [9fans] anyone put their venti on an SSD?
i have 60GB intel ssd in my new fileserver holding the cwfs worm cache. no problems so far. but the machine is just up for two weeks. its an experiment. if it breaks i have spare sata drive that could replace it. the worm is on a mirror with traditional mechanical harddrives. cpu% cat '#S/sdC0/ctl' inquiry INTEL SSDSC2CT060A3 config 0040 capabilities 2F00 dma 00550040 dmactl 00550040 rwm 16 rwmctl 0 lba48always off model INTEL SSDSC2CT060A3 serial BTMP31010344060AGN firm300i featlba llba smart power nop ata8 sct geometry 117231408512 alignment 512 0 missirq 0 sloop 0 irq 2233361 2233358 bsy 0 0 nildrive3 part data 0 117231408 part plan9 63 117226305 part 9fat 63 204863 part nvram 204863 204864 part fscache 204871 67313735 -- cinap
Re: [9fans] anyone put their venti on an SSD?
I tried putting venti on an ssd with similar results. Fossil, kenfs, and cwfs all worked fine on that drive though. I think it was one of the earlier Intels. On May 3, 2013, at 16:59, ge...@plan9.bell-labs.com wrote: > I tried putting our index on a single OCZ SSD and it died during buildindex. > The SSD was completely unresponsive thereafter, which is pretty > appalling behaviour for a storage device. Having since sworn off > OCZ, I would try again with a pair of Intel 330s in a RAID. >
Re: [9fans] anyone put their venti on an SSD?
I tried putting our index on a single OCZ SSD and it died during buildindex. The SSD was completely unresponsive thereafter, which is pretty appalling behaviour for a storage device. Having since sworn off OCZ, I would try again with a pair of Intel 330s in a RAID.
Re: [9fans] anyone attempted to build ghostscript recently?
> Russ Cox wrote a > mkfile for it when he ported it to Plan 9. thanks, yes I looked at ghostscript a year or two ago but they seem to have changed their directory layout and modifying the mkfile was not straightforward. My need is for postscript to pcl6 for the printer we have, currently I run ghostscript under linuxemu which works but I I would prefer to have a working native port. I will try again. -Steve
Re: [9fans] Scrolling considered harmful
On Fri, May 03, 2013 at 02:57:12PM -0400, erik quanstrom wrote: > > the problem is that the VBE calls that are used to set up > various video modes jump to vendor-provided real mode > code that is often buggy. the reason for emulation is > (a) to avoid problems associated with real-mode code > triggering interrupts the partial real-mode implementation > > the 9 kernels provide is not prepared to handle, and > (b) to avoid invalid accesses caused by buggy real-mode > code. > I will first master vgadb, plan9.ini and aux/vga to get a more sensible vgasize. And afterwards I will insert aux/realemu to see if the freeze do not happen again. -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Scrolling considered harmful
> I have retrieved atom aux/realemu and I will have to test. > > But before, I will have to read the aux/vga sources to understand what > it expects. Because aux/vga -p gives me all the informations about the > vesa supported modes of the card, and even the monitor settings (I > wonder that the problem is here, that is monitor and card "discuss" and > the software is not part of the discussion). The informations (vesa: the > RADEON card; edid: the monitor 1600x900): the problem is that the VBE calls that are used to set up various video modes jump to vendor-provided real mode code that is often buggy. the reason for emulation is (a) to avoid problems associated with real-mode code triggering interrupts the partial real-mode implementation the 9 kernels provide is not prepared to handle, and (b) to avoid invalid accesses caused by buggy real-mode code. yes it sounds implausable that the vendor code could be that broken, but it's true! - erik
Re: [9fans] anyone attempted to build ghostscript recently?
On Fri, May 3, 2013 at 10:38 AM, erik quanstrom wrote: > > Yes... But this is also why, concurrently, work has to be done to get > > rid of some unnecessities: that documents produced on Plan9 be viewable > > on Plan9 with only Plan9 means (external documents are another problem). > > ghostscript already renders plan 9 produced pdf just fine. > so that problem is solved, and there's no need to do anything. > > what we need is better access to externally produced documents. > So, skipping interactivity, what about a pdf2pdf filter? -Jack
Re: [9fans] Scrolling considered harmful
On Tue, Apr 23, 2013 at 11:18:37AM -0400, erik quanstrom wrote: > > i have seen that some ati cards are not happy with some modes. > you may wish to try cinap's realemu which is at > > 9fs atom # srv $nflag -q tcp!atom.9atom.org atom && > # mount $nflag /srv/atom /n/atom atom > /n/atom/plan9/386/bin/aux/realemu > > if realemu is run before aux/vga, you may have better luck. > some bioses allow one to set the amount of video memory. > that might be worth checking, too. > I have retrieved atom aux/realemu and I will have to test. But before, I will have to read the aux/vga sources to understand what it expects. Because aux/vga -p gives me all the informations about the vesa supported modes of the card, and even the monitor settings (I wonder that the problem is here, that is monitor and card "discuss" and the software is not part of the discussion). The informations (vesa: the RADEON card; edid: the monitor 1600x900): vesa flagUlinear|Hlinear vesa sigVESA 2.0 vesa oemATI RADEON 9200 1.0 vesa vendor ATI Technologies Inc. vesa productV280 vesa rev01.00 vesa cap 8-bit-dac vesa mem134217728 vesa mode 0x6a 800x600x4 m4 planar vesa mode 0x102 800x600x4 m4 planar vesa mode 0x104 1024x768x4 m4 planar vesa mode 0x182 320x200x8 m8 packed vesa mode 0x10d 320x200x15 r5g5b5 direct vesa mode 0x10e 320x200x16 r5g6b5 direct vesa mode 0x10f 320x200x24 r8g8b8 direct vesa mode 0x120 320x200x32 x8r8g8b8 direct vesa mode 0x192 320x240x8 m8 packed vesa mode 0x193 320x240x15 r5g5b5 direct vesa mode 0x194 320x240x16 r5g6b5 direct vesa mode 0x195 320x240x24 r8g8b8 direct vesa mode 0x196 320x240x32 x8r8g8b8 direct vesa mode 0x1a2 400x300x8 m8 packed vesa mode 0x1a3 400x300x15 r5g5b5 direct vesa mode 0x1a4 400x300x16 r5g6b5 direct vesa mode 0x1a5 400x300x24 r8g8b8 direct vesa mode 0x1a6 400x300x32 x8r8g8b8 direct vesa mode 0x1b2 512x384x8 m8 packed vesa mode 0x1b3 512x384x15 r5g5b5 direct vesa mode 0x1b4 512x384x16 r5g6b5 direct vesa mode 0x1b5 512x384x24 r8g8b8 direct vesa mode 0x1b6 512x384x32 x8r8g8b8 direct vesa mode 0x1c2 640x350x8 m8 packed vesa mode 0x1c3 640x350x15 r5g5b5 direct vesa mode 0x1c4 640x350x16 r5g6b5 direct vesa mode 0x1c5 640x350x24 r8g8b8 direct vesa mode 0x1c6 640x350x32 x8r8g8b8 direct vesa mode 0x100 640x400x8 m8 packed vesa mode 0x183 640x400x15 r5g5b5 direct vesa mode 0x184 640x400x16 r5g6b5 direct vesa mode 0x185 640x400x24 r8g8b8 direct vesa mode 0x186 640x400x32 x8r8g8b8 direct vesa mode 0x101 640x480x8 m8 packed vesa mode 0x110 640x480x15 r5g5b5 direct vesa mode 0x111 640x480x16 r5g6b5 direct vesa mode 0x112 640x480x24 r8g8b8 direct vesa mode 0x121 640x480x32 x8r8g8b8 direct vesa mode 0x103 800x600x8 m8 packed vesa mode 0x113 800x600x15 r5g5b5 direct vesa mode 0x114 800x600x16 r5g6b5 direct vesa mode 0x115 800x600x24 r8g8b8 direct vesa mode 0x122 800x600x32 x8r8g8b8 direct vesa mode 0x105 1024x768x8 m8 packed vesa mode 0x116 1024x768x15 r5g5b5 direct vesa mode 0x117 1024x768x16 r5g6b5 direct vesa mode 0x118 1024x768x24 r8g8b8 direct vesa mode 0x123 1024x768x32 x8r8g8b8 direct vesa mode 0x107 1280x1024x8 m8 packed vesa mode 0x119 1280x1024x15 r5g5b5 direct vesa mode 0x11a 1280x1024x16 r5g6b5 direct vesa mode 0x11b 1280x1024x24 r8g8b8 direct vesa mode 0x124 1280x1024x32 x8r8g8b8 direct vesa mode 0x109 132x25x4 m4 text vesa mode 0x10a 132x43x4 m4 text vesa mode 0x130 132x44x4 m4 text edid mfrIVM edid serialstr 1103020910036 edid name PLE2008HDS edid product21404 edid serial 10036 edid version1.3 edid mfrdate2012.9 edid size (cm) 45x25 edid gamma 2.20 edid vert (Hz) 55-76 edid horz (Hz) 3-84000 edid pclkmax17000 edid flags activeoff edid 640x480x0@60Hz clock=25.175 shb=648 ehb=792 ht=800 vrs=490 vre=492 vt=525 hsync=- vsync=- edid 640x480x0@73Hz clock=31.5 shb=648 ehb=824 ht=832 vrs=489 vre=492 vt=520 hsync=- vsync=- edid 640x480x0@75Hz clock=31.5 shb=640 ehb=840 ht=840 vrs=481 vre=484 vt=500 hsync=- vsync=- edid 800x600x0@56Hz clock=36 shb=800 ehb=1024 ht=1024 vrs=601 vre=603 vt=625
Re: [9fans] anyone attempted to build ghostscript recently?
> Yes... But this is also why, concurrently, work has to be done to get > rid of some unnecessities: that documents produced on Plan9 be viewable > on Plan9 with only Plan9 means (external documents are another problem). ghostscript already renders plan 9 produced pdf just fine. so that problem is solved, and there's no need to do anything. what we need is better access to externally produced documents. - erik
[9fans] [gsoc] Dart9P
Hello! I'm aware that it's rather late for this, and that I very nearly missed the submission deadline, but well... real life had other plans for me. Still, I'd just love to work on Plan9 over the summer, and here is my proposal: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/bawr/4002 Comments are welcome, even if the Melange version is frozen I'll probably update an HTML version for my own reference, if nothing else. Cheers! /bawr
Re: [9fans] anyone attempted to build ghostscript recently?
On Fri, May 03, 2013 at 08:10:26PM +0200, Aram H?v?rneanu wrote: > > But in this case, there are > > probably online PDF viewers... > > But no Plan 9 browsers. Yes... But this is also why, concurrently, work has to be done to get rid of some unnecessities: that documents produced on Plan9 be viewable on Plan9 with only Plan9 means (external documents are another problem). And this is why I prefer TeX other *roff: not because of some religious war; but because TeX is a whole system, including fonts and mean to make them, and there is a shortest path to full autonomy. (And this is why kerTeX will still produce DVI, even with extensions, and not directly PDF.) What would be fun would be a... PDF to DVI converter (because it will mean a huge part of "dropping" features---/dev/null is something I can not do without.) -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] anyone attempted to build ghostscript recently?
> But in this case, there are > probably online PDF viewers... But no Plan 9 browsers. -- Aram Hăvărneanu
Re: [9fans] anyone attempted to build ghostscript recently?
On Fri, May 03, 2013 at 09:14:18AM -0800, Jack Johnson wrote: > Is a PS/PDF library something that might benefit from reconstruction in Go? > Or is it just a spaghetti mess? Whatever the way (porting existing to Go or writing from scratch), a Go version would be an improvement against a C++ one with gigabytes of dependencies. This may be (partly) achievable with a PDF library, I doubt something like Ghostscript is achievable (and I even wonder if that makes sense to reimplement a full PostScript interpreter). The problem is: if this is just to render documents created on Plan9, a minimum is required, but one could get rid entirely of PostScript or PDF. If this is to view an external PDF document, or to render an external PS document, that may use the latest version (for PDF) or a lot of features (for PS), you're skrewed. But in this case, there are probably online PDF viewers... -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] anyone attempted to build ghostscript recently?
On May 3, 2013, at 12:16 PM, erik quanstrom wrote: > On Fri May 3 13:15:41 EDT 2013, knapj...@gmail.com wrote: > >> Is a PS/PDF library something that might benefit from reconstruction in Go? >> Or is it just a spaghetti mess? > > go or c, a fresh implementation might be an improvement, > and given the weight of some of the other options, might be > more time-efficient than one would think. There are several somewhat portable pdf rendering libraries out there. Some with mostly C and a little sprinkling of C++ (like mupdf.com). If we had a Javascript interpreter and support or SVG then https://wiki.mozilla.org/PDF.js might be an option once that group irons out the kinks. -jas
Re: [9fans] anyone attempted to build ghostscript recently?
What about mupdf? It has few dependecies [1] http://mupdf.com/doc/ [1] http://git.ghostscript.com/?p=mupdf.git;a=tree;f=thirdparty;hb=HEAD pmarin. On Fri, May 3, 2013 at 7:16 PM, erik quanstrom wrote: > On Fri May 3 13:15:41 EDT 2013, knapj...@gmail.com wrote: > > > Is a PS/PDF library something that might benefit from reconstruction in > Go? > > Or is it just a spaghetti mess? > > go or c, a fresh implementation might be an improvement, > and given the weight of some of the other options, might be > more time-efficient than one would think. > > - erik > >
Re: [9fans] anyone attempted to build ghostscript recently?
On Fri May 3 13:15:41 EDT 2013, knapj...@gmail.com wrote: > Is a PS/PDF library something that might benefit from reconstruction in Go? > Or is it just a spaghetti mess? go or c, a fresh implementation might be an improvement, and given the weight of some of the other options, might be more time-efficient than one would think. - erik
Re: [9fans] anyone attempted to build ghostscript recently?
Is a PS/PDF library something that might benefit from reconstruction in Go? Or is it just a spaghetti mess?
Re: [9fans] anyone attempted to build ghostscript recently?
On Fri, May 03, 2013 at 12:26:47PM -0400, a...@9srv.net wrote: > ...and how does that help me read a pre-existing PDF document? Reading a pre-existing PDF document does not need ghostscript. PDF is supposed to be in the dvi class, and predigested rendering. So it should be easier to "port" a PDF library... except that the existing ones are C++ and there is an inflation of "interactive" features (that keep Adobe cutting edge even if the language is documented and royalty free). So, reading existing things is one thing. Producing things that we are unable to render is another one. You may have the obligation of the former; not the latter. This the sense of my comment. -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Octets regexp
On Fri, May 03, 2013 at 09:15:27AM -0400, Tristan wrote: > > tcs -f 8859-1 > > will take your _binary_ files, and replace the bytes 0x80-0xff with the > unicode points U0080-U00ff, so you can use the standard regexps and tools > on them. and just convert back afterwards. > OK, mea culpa... since I'm french, I focused on the latin1 thinking this has something to do with my language and the custom to deal with latin1 on other systems. I guess I could create a keyboard that produces not UTF-8 but bytes so to have a mean to input bytes (without resorting to printf or whatever). Remains the problem of the rendering (or create a special font that displays octal, hexadecimal or whatever playing with the index of the glyphes; but this will work for octets, and will be more difficult if one wants to deal with wydes; impossible with tetras and octas). -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] anyone attempted to build ghostscript recently?
...and how does that help me read a pre-existing PDF document? --- Begin Message --- On Fri, May 03, 2013 at 03:18:40PM +0100, Steve Simon wrote: > Thinking of tackeling ghostscript again but failed at the first hurdle, > it needs autotools to build... Plan A, create a SmallScript borrowing the rasterizing routines of METAFONT and not aiming to be a full PostScript interpreter. Plan B, get rid of PostScript altogether and use TeX and METAFONT and/or fonts available with the glyphes, and render directly from dvi to pdf, dvi to raw (image), dvi to pcl; even using virtual fonts to render approximately fonts not present with glyphes definition for previsualisation, and using dvips for direct printing to real PostScript interpreters (with embedded compliant PostScript standard fonts). Isn't there a sentence about "wanting a banana, and being forced to have a Gorilla handing the banana with the whole jungle around"? -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C--- End Message ---
Re: [9fans] anyone attempted to build ghostscript recently?
On Fri, May 03, 2013 at 03:18:40PM +0100, Steve Simon wrote: > Thinking of tackeling ghostscript again but failed at the first hurdle, > it needs autotools to build... Plan A, create a SmallScript borrowing the rasterizing routines of METAFONT and not aiming to be a full PostScript interpreter. Plan B, get rid of PostScript altogether and use TeX and METAFONT and/or fonts available with the glyphes, and render directly from dvi to pdf, dvi to raw (image), dvi to pcl; even using virtual fonts to render approximately fonts not present with glyphes definition for previsualisation, and using dvips for direct printing to real PostScript interpreters (with embedded compliant PostScript standard fonts). Isn't there a sentence about "wanting a banana, and being forced to have a Gorilla handing the banana with the whole jungle around"? -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] anyone attempted to build ghostscript recently?
> Thinking of tackeling ghostscript again but failed at the first hurdle, > it needs autotools to build... > > Anyone attempted this? Ghostscript 8.53 was already using autotools, but Russ Cox wrote a mkfile for it when he ported it to Plan 9. The current mkfile is already able to compile Ghostscript up to 8.63, with almost no change. However, I'm only using Ghostscript 8.56, since I wasn't able to run the following releases properly. You could probably use the current mkfile as a base and expend it. There are probably changes needed in the code that should be pushed upstream. -- David du Colombier
Re: [9fans] anyone attempted to build ghostscript recently?
On Fri, May 03, 2013 at 10:22:13AM -0400, erik quanstrom wrote: > > one question, though. are there better alternatives than ghostscript evince is a poppler frontend; poppler's problematic dependencies include glib and cmake. poppler is descended from xpdf, whose problematic dependencies are include freetype and motif, although I believe the actual pdf rendering code doesn't invoke any motif. khm
Re: [9fans] anyone put their venti on an SSD?
I have not yet, but i've been meaning to play around some with different arrangements for different parts. Please let us know if you hear anything interesting. Anthony
Re: [9fans] anyone attempted to build ghostscript recently?
On Fri May 3 10:19:43 EDT 2013, st...@quintile.net wrote: > Thinking of tackeling ghostscript again but failed at the first hurdle, > it needs autotools to build... oh please do! one question, though. are there better alternatives than ghostscript for pdf? ghostscript usually fails for simple documents on my amd64 machine with (to me) inscrutible postscript stack traces. i find that often ghostscript also fails on linux for the same document, but e.g. evince does not. - erik
[9fans] anyone put their venti on an SSD?
what the subject says, anyone put their venti (those that use it) on a solid state disk? -Steve
[9fans] anyone attempted to build ghostscript recently?
Thinking of tackeling ghostscript again but failed at the first hurdle, it needs autotools to build... Anyone attempted this? -Steve
Re: [9fans] Rune update may have broken compilations
On Fri May 3 08:56:58 EDT 2013, lu...@proxima.alt.za wrote: > ... or I may just be doing something inappropriate. But right now, I > get: > > 5c -FTVw runebase.c one thing not in the sources version of 21-bit runes is the ability to regenerate the rune tables automaticly from the official UnicodeData.txt. the scripts in /n/atom/plan9/sys/src/cmd/runetype give one that ability. since i had this same issue during conversion, the scripts omit characters biggern than Maxrune. these scripts made the conversions from 5.2 to 6.0 and from 6.0 to 6.1 a matter of typing "mk". - erik
Re: [9fans] Rune update may have broken compilations
On Fri May 3 09:31:11 EDT 2013, 0in...@gmail.com wrote:
> The procedure is:
>
> 1. remove runebase from /sys/src/libc/port/mkfile
> 2. cd /sys/src/libc && mk install && mk clean
> 3. for(i in /sys/src/cmd/8?) {cd $i && mk install && mk clean}
> 4. add runebase in /sys/src/libc/port/mkfile
> 5. cd /sys/src/libc && mk install && mk clean
> 6. cd /sys/src && mk install && mk clean
alternately, download /n/atom/plan9/$objtype/bin/$O^c
and goto step 6.
- erik
Re: [9fans] Rune update may have broken compilations
The procedure is:
1. remove runebase from /sys/src/libc/port/mkfile
2. cd /sys/src/libc && mk install && mk clean
3. for(i in /sys/src/cmd/8?) {cd $i && mk install && mk clean}
4. add runebase in /sys/src/libc/port/mkfile
5. cd /sys/src/libc && mk install && mk clean
6. cd /sys/src && mk install && mk clean
--
David du Colombier
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
2013/5/1 Steve Simon : > There has been a win32.c in the labs distribution of rc(1) for years > but it has never (to my knowledge) worked. > > I did a major overhall of the win32 port and back ports of a few > plan9 tools to posix (I know, I know), and packaged the whole thing up. sounds like it deserves to become submitted as a patch. -- - Yaroslav
Re: [9fans] Octets regexp
> > if we're talking about xd, i'll suggest 'tcs -f 8859-1' again in which case: > My question was _not_ related to text, and _not_ related to "french" i.e. > 8859-1. I know how to deal with this. tcs -f 8859-1 will take your _binary_ files, and replace the bytes 0x80-0xff with the unicode points U0080-U00ff, so you can use the standard regexps and tools on them. and just convert back afterwards. maybe it's not meant to be used that way, but it _works_. try it. have fun! tristan -- All original matter is hereby placed immediately under the public domain.
[9fans] Rune update may have broken compilations
... or I may just be doing something inappropriate. But right now, I get: 5c -FTVw runebase.c f0 a4 8b ae 20 f0 a2 a1 8a 20 f0 a2 a1 84 20 f0 a3 8f 95 20 f0 a5 89 89 20 runebase.c:1255 illegal rune in string runebase.c:1255 illegal rune in string runebase.c:1352 illegal rune in string runebase.c:1352 illegal rune in string runebase.c:1353 illegal rune in string runebase.c:1353 illegal rune in string runebase.c:1354 illegal rune in string runebase.c:1354 illegal rune in string runebase.c:1358 illegal rune in string runebase.c:1358 illegal rune in string runebase.c:1359 illegal rune in string too many errors mk: 5c -FTVw runebase.c : exit status=rc 137119: 5c 137121: error mk: for(i in 9sys ... : exit status=rc 136165: rc 136939: mk 136941: error mk: date for (i ... : exit status=rc 135760: rc 136100: mk 136164: error when compiling libc, whether for the 386 or the arm. I'd appreciate suggestions on how to get out of this trouble. I've already made sure both 8c and 5c match the versions in sources. ++L
Re: [9fans] Octets regexp
On Thu, May 02, 2013 at 04:17:11PM -0400, 9p...@imu.li wrote: > > if we're talking about xd, i'll suggest 'tcs -f 8859-1' again in which case: > My question was _not_ related to text, and _not_ related to "french" i.e. 8859-1. I know how to deal with this. -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
