Re: [fossil-users] TH1: support for octal and hexadecimal numbers in expressions
2014-04-03 23:23 GMT+02:00 Sergei Gavrikov sergei.gavri...@gmail.com: It seems that should not reload isdigit validator for octal and binary numbers, otherwise early break on illegal digit returns bad tokens: for example, for 0b2 sequence thNextNumber() will return 0b token, for 0o8 sequence it will return 0o. But, tokens should be 0b2 or 0o8. Only hexadecimal numbers is a case to change the validator. An additional issue is that binary/octal/hex numbers cannot contain dots, so they must be handled separately anyway. Done here: http://fossil-scm.org/index.html/info/a306f771d8 Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] TH1: support for octal and hexadecimal numbers in expressions
On Fri, Apr 4, 2014 at 10:28 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: An additional issue is that binary/octal/hex numbers cannot contain dots, so they must be handled separately anyway. Done here: http://fossil-scm.org/index.html/info/a306f771d8 Why can't n-ary numbers have dots? 0b1.11 is a perfectly valid representation of 1.75. Mark ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] TH1: support for octal and hexadecimal numbers in expressions
On Fri, Apr 4, 2014 at 10:54 AM, Mark Janssen mpc.jans...@gmail.com wrote: Why can't n-ary numbers have dots? 0b1.11 is a perfectly valid representation of 1.75. i would argue that in the context of fossil, which rarely uses floating point numbers and never uses binary numbers, such a feature is YAGNI[1]. Maybe if you want to output your UUIDs in binary format... that might be fun to do each year on April 1st. [1] http://en.wikipedia.org/wiki/You_aren't_gonna_need_it -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] TH1: support for octal and hexadecimal numbers in expressions
2014-04-04 10:54 GMT+02:00 Mark Janssen mpc.jans...@gmail.com: Why can't n-ary numbers have dots? 0b1.11 is a perfectly valid representation of 1.75. $ tclsh8.6 % expr 0+0b1.1 missing operator at _@_ in expression 0+0b1_@_.1 % Since th1 is supposed to be a subset of Tcl, I don't think that th1 should invent any syntax which Tcl doesn't support. (Feel free to write a Tcl TIP, but I don't think it has a high chance to be accepted.) Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] TH1: support for octal and hexadecimal numbers in expressions
2014-04-04 11:06 GMT+02:00 Jan Nijtmans jan.nijtm...@gmail.com: Since th1 is supposed to be a subset of Tcl, I don't think that th1 should invent any syntax which Tcl doesn't support. (Feel free to write a Tcl TIP, but I don't think it has a high chance to be accepted.) Noted that the floating point format accepted for TH1 is a subset of that accepted by Tcl already: $ tclsh8.6 % expr 0+1. 1.0 % expr 0+1e-1 0.1 $ fossil test-th-eval expr 0+1. TH_ERROR: expected number, got: 1. $ fossil test-th-eval expr 0+1e-1 TH_ERROR: syntax error in expression: 0+1e-1 I'm not going to enhance fossil to accept the same floating point syntax as Tcl (since I simply don't need it), but if someone else needs it I wouldn't object. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] TH1: support for octal and hexadecimal numbers in expressions
On Fri, 4 Apr 2014, Jan Nijtmans wrote: An additional issue is that binary/octal/hex numbers cannot contain dots, so they must be handled separately anyway. Done here: http://fossil-scm.org/index.html/info/a306f771d8 [the issues went away] Thank you very much! Now we have the comfortable way to manage any numbers on embedded targets. Regards, Sergei ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] TH1: support for octal and hexadecimal numbers in expressions
I think th1 happens to basically be a subset of Tcl, but is not designed to strictly be a subset of Tcl, fwiw. On 4/4/14, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014-04-04 10:54 GMT+02:00 Mark Janssen mpc.jans...@gmail.com: Why can't n-ary numbers have dots? 0b1.11 is a perfectly valid representation of 1.75. $ tclsh8.6 % expr 0+0b1.1 missing operator at _@_ in expression 0+0b1_@_.1 % Since th1 is supposed to be a subset of Tcl, I don't think that th1 should invent any syntax which Tcl doesn't support. (Feel free to write a Tcl TIP, but I don't think it has a high chance to be accepted.) Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] [fossil all close]
It occurred to me that a good exercise for reacquainting myself with the Fossil source tree (it's been awhile since DRH's presentation on same) would be to add a [fossil all close] command. Plus I actually could use such a thing right about now since I'm reorganizing repositories and checkouts, and that requires a lot of closing. [fossil all close] is there in my checkout, and it works, but I'm not satisfied until it's polished, and that means error messages being useful. For example, saying current directory is not within an open checkout is most unhelpful when there's no indication which directory mistakenly found its way into [fossil all ls -c]. My design approach was simply to add close --chdir with useCheckouts and quiet to all_cmd, but this leads to confusing errors whenever anything is shy of perfect. I suppose I could ditch quiet, but I thought I might try improving close_cmd to say which checkout it's talking about. However, I did not want to break compatibility by changing the format of warning and error messages for modes of operation currently in use. So I figured I'd make it explicitly name the checkout whenever --chdir is in use. (Also silently ignore the not an open checkout error.) Just call find_option(chdir), right? Wrong. main() already snarfed it up, and find_option() has the lovely side effect of calling remove_from_argv() upon match. Could add global variables, or could add a --header option or --verbose or whatever, but none of these approaches appeal to me since they are simply workarounds for a design limitation elsewhere. The goal isn't to bang something out quickly, it's to explore the code, so please bear with me as I obsess over normally unimportant details. Not sure if I'm actually asking anything. I'm just putting out some thoughts and impressions. Perhaps someone will have a suggestion. Or I could indeed turn off quiet mode and leave close_cmd() alone. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
