Csup cvsmode build discussion
Hello hackers, As some might know, I've been implementing CVSMode for csup over the last couple of months. Right now, I'm quite close to have it work (does not mean it will work perfect :)), but I encountered some issues regarding the inclusion of my lex and yacc files that I would like to discuss. It is assumed that the reader know what lex and yacc is. First of all, I implemented the RCS parser required to operate on RCS files using lex and yacc. Those are in FreeBSD userland, but the problem is they are wayy to outdated for csups need. The reason is mainly because they don't support: 1) reentrancy (needed since csup uses two threads, one to send information to the server regarding it's files, and one to recieve information on how a file is to be updated). 2) prefixing of lex/yacc output. Not a big deal, but easy if one doesn't need to have to work around it. 3) parameter passing. Part of the reentrancy requirement but useful if one would extend the arguments to a parser. Because of this, I've been compiling the parser and tokenizer with the help of bison and flex from ports. Now, the base system already have flex, but the flex version in base is heavily outdated (version 2.5.4 versus 2.5.34 in ports) and does not support reentrancy. Is there a reason why it's outdated? What I can think of is that it is either unmaintained, or that developers want it to disappear from base. The yacc version in base is pretty old too and does not support reentrancy. I would like to not have to hack it up to support this to avoid using bison, (And I suspect importing bison into base is going to happen over someones dead body :)). So, I'm asking you, how should I best deal with this? Should I a) Just include the _generated_ parser and tokenizer (e.g the output from bison and flex) and just include the yacc and lex files in case someone wants to work more on it? b) Modify parser to be non-reentrant and solve my issues with locks. c) Import bison into base and update flex version. d) Insert your fantastic idea here Alternative 'a' is my favorite, and seems to be the easiest way to avoid a heavy inpact on the base system, but again it will complicate procedure of modifying the parser since one have to use the correct build tools etc. 'b' would lead to performance loss and I would very much like to avoid it. 'c' would take a lot of work and I think many would protest on importing bison (including me if I were not biased with needing it and all :)) What I ask of you is comments on these alternatives as well as inserting your fantastic idea if you happen to have one :) -- Ulf Lilleengen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Csup cvsmode build discussion
Hi, On 16 Jan 2008, at 09:33, Ulf Lilleengen wrote: Hello hackers, As some might know, I've been implementing CVSMode for csup over the last couple of months. Right now, I'm quite close to have it work (does not mean it will work perfect :)), but I encountered some issues regarding the inclusion of my lex and yacc files that I would like to discuss. It is assumed that the reader know what lex and yacc is. First of all, I implemented the RCS parser required to operate on RCS files using lex and yacc. Those are in FreeBSD userland, but the problem is they are wayy to outdated for csups need. The reason is mainly because they don't support: 1) reentrancy (needed since csup uses two threads, one to send information to the server regarding it's files, and one to recieve information on how a file is to be updated). 2) prefixing of lex/yacc output. Not a big deal, but easy if one doesn't need to have to work around it. 3) parameter passing. Part of the reentrancy requirement but useful if one would extend the arguments to a parser. Because of this, I've been compiling the parser and tokenizer with the help of bison and flex from ports. Now, the base system already have flex, but the flex version in base is heavily outdated (version 2.5.4 versus 2.5.34 in ports) and does not support reentrancy. Is there a reason why it's outdated? What I can think of is that it is either unmaintained, or that developers want it to disappear from base. The yacc version in base is pretty old too and does not support reentrancy. I would like to not have to hack it up to support this to avoid using bison, (And I suspect importing bison into base is going to happen over someones dead body :)). So, I'm asking you, how should I best deal with this? Should I a) Just include the _generated_ parser and tokenizer (e.g the output from bison and flex) and just include the yacc and lex files in case someone wants to work more on it? b) Modify parser to be non-reentrant and solve my issues with locks. c) Import bison into base and update flex version. d) Insert your fantastic idea here Alternative 'a' is my favorite, and seems to be the easiest way to avoid a heavy inpact on the base system, but again it will complicate procedure of modifying the parser since one have to use the correct build tools etc. 'b' would lead to performance loss and I would very much like to avoid it. 'c' would take a lot of work and I think many would protest on importing bison (including me if I were not biased with needing it and all :)) What I ask of you is comments on these alternatives as well as inserting your fantastic idea if you happen to have one :) I'm not going to comment on the merits of flex and bison as I like to be polite :-) I'd suggest (a), but package the yacc and lex source files up as a port so that they are in CVS and can readily be rebuilt if necessary. Why do you want prefixing? And precisely what do you want to do with parameters? -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
disk throughput
i've got this running in one term: systat -iostat 1 and this in another term: dd if=/dev/acd0 bs=2048 count=123456 | md5 apparently the system only knows about throughput of mounted disks? is that a bug or a feature? -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - Only sick music makes money today. -- Friedrich Nietzsche, Der Fall Wagner, 1888 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disk throughput
On Wed, Jan 16, 2008 at 10:48:27PM +1300, Atom Smasher wrote: i've got this running in one term: systat -iostat 1 and this in another term: dd if=/dev/acd0 bs=2048 count=123456 | md5 apparently the system only knows about throughput of mounted disks? It doesn't seem to know about ata CD drives, SCSI CD drives work fine. Use gstat, which retrieves statistics at a different layer. You should use a multiple of 2k (e.g. 64k) for blocksize though. Just using 2k is likely to be much slower. is that a bug or a feature? I would say it's a missing feature in acd driver. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Csup cvsmode build discussion
On Wed, Jan 16, 2008 at 11:08:20AM +, Bob Bishop wrote: Hi, On 16 Jan 2008, at 09:33, Ulf Lilleengen wrote: Hello hackers, As some might know, I've been implementing CVSMode for csup over the last couple of months. Right now, I'm quite close to have it work (does not mean it [...] What I ask of you is comments on these alternatives as well as inserting your fantastic idea if you happen to have one :) I'm not going to comment on the merits of flex and bison as I like to be polite :-) I'd suggest (a), but package the yacc and lex source files up as a port so that they are in CVS and can readily be rebuilt if necessary. Perhaps. Not very pretty. Why do you want prefixing? And precisely what do you want to do with parameters? Prefixing is needed since csup already have a configuration parser written in lex/yacc and therefore needed to avoid conflicts. Parameters is nice if one were to modify the parser to take extra arguments, I don't have a concrete example for it yet, but it's nonetheless a requirement for reentrancy. An alternative d) that I got from Maxime is that I'll take a look and see if I can use a parser from cvsync or from the previous SoC 2005 work, which I think is a good idea. -- Ulf Lilleengen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Csup cvsmode build discussion
On 2008-01-16 10:33:02 (+0100), Ulf Lilleengen [EMAIL PROTECTED] wrote: Now, the base system already have flex, but the flex version in base is heavily outdated (version 2.5.4 versus 2.5.34 in ports) and does not support reentrancy. Is there a reason why it's outdated? What I can think of is that it is either unmaintained, or that developers want it to disappear from base. I think it's just unmaintained in base ... I wonder what it would take to update it. /me takes a look - Philip -- Philip PaepsPlease don't Cc me, I am [EMAIL PROTECTED] subscribed to the list. Da da da da da da da da da, yeah yeah yeah yeah, da da da da da da da da da, yeah yeah yeah yeah... -- Various people singing along to Man On The Moon without knowing the words ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Csup cvsmode build discussion
On Wed, Jan 16, 2008 at 02:32:14PM +0100 I heard the voice of Ulf Lilleengen, and lo! it spake thus: On Wed, Jan 16, 2008 at 11:08:20AM +, Bob Bishop wrote: Why do you want prefixing? Prefixing is needed since csup already have a configuration parser written in lex/yacc and therefore needed to avoid conflicts. Does lex's -P and yacc's -p not rewrite enough? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Csup cvsmode build discussion
On Wed, Jan 16, 2008 at 07:41:47AM -0600, Matthew D. Fuller wrote: On Wed, Jan 16, 2008 at 02:32:14PM +0100 I heard the voice of Ulf Lilleengen, and lo! it spake thus: On Wed, Jan 16, 2008 at 11:08:20AM +, Bob Bishop wrote: Why do you want prefixing? Prefixing is needed since csup already have a configuration parser written in lex/yacc and therefore needed to avoid conflicts. Does lex's -P and yacc's -p not rewrite enough? This was just pointed out to me. Sorry for the bad research. -- Ulf Lilleengen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Csup cvsmode build discussion
Hi, On 16 Jan 2008, at 13:32, Ulf Lilleengen wrote: On Wed, Jan 16, 2008 at 11:08:20AM +, Bob Bishop wrote: [...] Why do you want prefixing? And precisely what do you want to do with parameters? Prefixing is needed since csup already have a configuration parser written in lex/yacc and therefore needed to avoid conflicts. You can alternatively avoid conflicts by putting both grammars in the same file, with an entry rule which refers to one or other of the two grammars' real entries based on a defined token. You then arrange for the lexer to supply the appropriate value of the switch token each time the parser is started up. Parameters is nice if one were to modify the parser to take extra arguments, I don't have a concrete example for it yet, but it's nonetheless a requirement for reentrancy. [etc] You may be able to do this using a variation on the above trick. -- Ulf Lilleengen -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Csup cvsmode build discussion
On ons, jan 16, 2008 at 02:39:26pm +, Bob Bishop wrote: Hi, On 16 Jan 2008, at 13:32, Ulf Lilleengen wrote: On Wed, Jan 16, 2008 at 11:08:20AM +, Bob Bishop wrote: [...] Why do you want prefixing? And precisely what do you want to do with parameters? Prefixing is needed since csup already have a configuration parser written in lex/yacc and therefore needed to avoid conflicts. You can alternatively avoid conflicts by putting both grammars in the same file, with an entry rule which refers to one or other of the two grammars' real entries based on a defined token. You then arrange for the lexer to supply the appropriate value of the switch token each time the parser is started up. As noted by others in this thread, the lex and yacc versions in base does in fact support prefixing. Thus, the only problem is reentrancy, which I've commented on below. Parameters is nice if one were to modify the parser to take extra arguments, I don't have a concrete example for it yet, but it's nonetheless a requirement for reentrancy. [etc] You may be able to do this using a variation on the above trick. So for the reentrancy part, what you suggest is that instead of passing the argument to the reentrant parser, I create the global variables for each thread using the parser, and then use one or the other global variables depending on which thread is calling the parser? It's a very interesting trick, and I think it might work. It's not very scalable, but it's a good workaround to be able to use the base system lex and yacc. However, this might only fix the issue with yacc if I'm thinking correctly, because the lexer also needs to be told about this for reentrancy. (But perhaps a much smaller problem since it's a matter of updating the lex version in base). Anyway, thanks for a useful suggestion. I'll try it out. -- Ulf Lilleengen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Csup cvsmode build discussion
On 2008-01-16 16:06:56 (+0100), Ulf Lilleengen [EMAIL PROTECTED] wrote: However, this might only fix the issue with yacc if I'm thinking correctly, because the lexer also needs to be told about this for reentrancy. (But perhaps a much smaller problem since it's a matter of updating the lex version in base). I found that updating the lex in base was surprisingly easy. :-) I'll clean up my patches and post them for review later this evening. - Philip -- Philip PaepsPlease don't Cc me, I am [EMAIL PROTECTED] subscribed to the list. One day a tortoise will learn how to fly. -- (Terry Pratchett, Small Gods) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvidia working?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Nielsen wrote: Quoting Chuck Robey [EMAIL PROTECTED]: I was wondering ... I have (I think) nvidia working on my box, or at least, I am calling out the nvidia driver in the xorg.conf, but I was wondering if there is any program that only works with the nvidia hardware, some way I can absolutely prove that I have the real nvidia card working here? Before I had it working, I was using the vesa driver, and most things look exactly the same, and if I could fine some program that shows the 8600GTS's abilities, I would sure like that. btw -questions would probably have been a better forum for this question than -hackers. The most straightforward approach is probably to review the output of your Xorg log, e.g. /var/log/Xorg.0.log. Output from the nvidia driver will be prefixed by NVIDIA (rather than VESA or NV if you were using a different driver). There is also x11/nvidia-settings port. It's a control panel of sorts that will show you nvidia-specific information. In theory it lets you control some settings as well but personally I've never found it useful for that. YMMV. Thanks! Looks like I really do finally have that card/driver working right, too. Sure 'preciate the ideas. JN -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHjj9wz62J6PPcoOkRAjmBAJ405DDYxex5XhZIXm7X+7OVJghXwwCfWoBp pJ1g1hqT6Vp7AEifghRGx+c= =1XCQ -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is Elf formatdocumented anywhere?
Yuri wrote: When I am trying to understand how Elf executable works I am only getting to few pages with very fragmentary information. Googling many constants like R_386_PC32, R_386_TLS_LD only yields some discussion references and code. Anybody knows where to read more about the Elf format? Does such document even exist? Yuri You can look at http://www.skyfree.org/linux/references/ELF_Format.pdf ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
