On Sat, Feb 20, 2016 at 12:25 AM, Warren Young <w...@etr-usa.com> wrote:
> No, libiconv comes to OS X via HPUX -> XPG4 -> SUS -> GNU: > > https://www.gnu.org/software/libiconv/ > https://en.wikipedia.org/wiki/Iconv > > Now that I think more about it, though, I think this isn’t a library > dependency chasing problem, it’s that iconv(3) and friends are built into > glibc on Linux. BSD and OS X don’t use glibc. > > (So we’re not affected by the recent remotely-exploitable game-over DNS > bug, hah!) > > Bottom line, -liconv will be required on more platforms than just OS X. > libfossil doesn't use it, so i see no reason to add -liconv to any platforms. If it's used in the Apple-specific bits (i think i recall seeing such-named APIs which porting over some filesystem-handling code), i see no reason to explicitly enable it for any other platforms. > > > > Removing the -export-dynamic line in the Makefile fixes this. > Apparently this is a GCC-> specific flag. > > > > Yes, and clang on linux blindly tolerates it. i'll remove it. > > I’m on OS X 10.10 still (current is 10.11) so it may be that clang only > learned about this flag in the past year or so. > i just looked for that flag... s2's build uses it (i can disable that w/o problems) but autosetup apparently also injects it: [stephan@host:~/cvs/fossil/libfossil]$ find . -type f | xargs grep 'export-dynamic' ./s2/Makefile: f-s2sh.BIN.LDFLAGS += -export-dynamic ./s2/Makefile~: f-s2sh.BIN.LDFLAGS += -export-dynamic ./th1ish/Makefile.in: fossi1ish.BIN.LDFLAGS += -export-dynamic ./th1ish/Makefile: fossi1ish.BIN.LDFLAGS += -export-dynamic ./th1ish/makefile.gnu: th1ish.BIN.LDFLAGS += -export-dynamic $(DL_LDFLAGS) ./th1ish/Makefile.in~: fossi1ish.BIN.LDFLAGS += -export-dynamic $(DL_LDFLAGS) ./autosetup/lib/cc-shared.tcl: define SH_LINKFLAGS -Wl,-export-dynamic ./autosetup/lib/cc-shared.tcl: define SH_LINKFLAGS -Wl,-export-dynamic i'm more hesitant to remove it from there. > I’ll think about it. The main obstacle (besides ENOTIME) is that I don’t > know your build system, so doing a platform-specific fix will require more > than my GNU make knowledge. > The build system is just a means to an ends. (Except for GNU Autotools, which are an end to the means.) > Should I send patches here, direct to you, or…? > To me, please. > I haven’t done copyright assignment with drh yet, for what that’s worth. > All of my Fossil patches have been minor things. > There's no need. In the past i was over-careful about only allowing contributions from people with a waiver on file with DRH, but i've since let up on that. > > It's not _really_ intended to be installed that way: it's intended to be > dropped in to client projects using its amalgamation form: > > I think it might be useful to have a Fossil shell in the path, if nothing > else for passing test commands around on the mailing list. One of the very, very, very first things i tried doing with fossil (back in 2008) was getting a shell mode added, but it's internal use of exit() for fail-fast behaviour makes a shell impractical because any error kills it (on the flip-side, it drastically reduces code complexity in most other cases by allowing us to simply not check for errors in many cases (e.g. memory allocation)). There's also a lot of global state which is not cleaned up, under the assumption that the app's about to exit (which will free up the memory), so a shell would continually leak even if it didn't exit. > > You might want to make that text conditional based on the build platform > so you’re only listing the legal platform alternatives. > > > > i only have 1 platform to test, so i dislike ifdef'ing stuff like that > :/. > > You can get it from termios: > > #include <stdio.h> > #include <termios.h> > #include <unistd.h> > > int main(void) > { > struct termios tp; > if (tcgetattr(STDIN_FILENO, &tp) == 0) { > printf("SIGINT triggered by ASCII %d\n", tp.c_cc[VINTR]); > } > return 0; > } > > You can map 1-26 to “Ctrl-%d” and 127 to “DEL”. > Nope. i pedantically stick to The C Standard exclusively except when absolutely needed for platform-specific features (loading DLLs), and this isn't one of those. My point about DEL wasn’t entirely serious, though, since Solaris probably > moved from DEL to Ctrl-C by default in Solaris 11 or 10. The last SysV I > used which used DEL by default was probably in the late 1990s. > Whether or not Ctrl-D works actually depends on the input source. The 3 currently supported ones (stdin, readline, and linenoise) all use the Unix-conventional Ctrl-D. > > It’s no good when two languages have the same keyword with such little > overlap in meaning. > > > > That's what the docs are for ;) > > That’s my point, actually. When two languages have the same keyword, a > programmer familiar with the other language says, “Oh, I know what ‘new’ > does; next!” and skips right on past that part of the docs. > There's a nice German phrase for that: "Selber Schuld." ("His own fault.") i think it was Alan W. Watts who wrote (paraphrased), "trying to solve a problem one does not understand is like trying to drive away the darkness with one's hands." > Saying RTFM here is like explaining away a semantic difference in “else > if”. > i don't get it. i say RTFM because all those points are explicitly covered in the TFM ;). > In fact, there are languages where if/else doesn’t do what you expect > coming from other languages, such as OCaml/F#: > > https://msdn.microsoft.com/en-us/library/dd233231.aspx > > Books on these languages make a point of clearing this confusion up early. > The s2 manual does as well, in the sections appropriate to those topics. > But here, you can avoid the confusion entirely by dropping “new” and going > with factory functions: > > var MyClass = function(arg1, arg2) { > var self = { > dataMember1: arg1, > dataMember2: arg2 / arg1, > method: function() { > s2.io.output("Hi, I am object " + self.dataMember1 + ':' + > self.dataMember2 + '!'); > } > }; > return self; > }; > In fact, s2 only recently got new() so that i could get people _away_ from factory functions because they cause code to end up having 10 different ways to instantiate 8 different things. Unifying that convention under one mechanism (new) simplified that greatly. > var obj = MyClass(1, 2); > obj.method(); > Nothing rules that out: const MyClass = proc(...){ return { ... } }; > That’s more in keeping with prototypical inheritance. > i fail to see how one or the other is more in line with prototypical inheritance. > The above compiles but doesn’t run in s2, apparently due to the difference > between JS closure and s2’s symbol lookup syntax. I can’t be bothered to > fix that up right now, but you get the idea. > s2's relationship to JS is simply one of syntax. It is most certainly not a JS wannabe/clone. Trying to compare them is like comparing perl and python (or C++ and C#, or any two similar-yet-different languages). > By the way, it would be nice if s2 allowed a comma after the } closing the > definition of “method”. It regularizes the syntax and allows you to freely > move definitions around inside an Object without special-casing the last > item. > i despise stray trailing commas, and put a lot of care into it _not_ allowing them. In fact, _allowing_ a trailing comma is a special-case. Disallowing them is the natural flow of the parser. > We get such syntax quirks from prose, but there’s no good reason to > re-perpetrate them in the far more rigorous world of computer languages. > i'm pedantic like this. These are _not_ the same, semantically speaking: [1], [1,], and by disallowing the trailing comma, all questions about "how does that behave" are eliminated before they happen because the answer is: s2> [1,] rc=2009 (CWAL_SCR_SYNTAX): s2_engine says error #2009 (CWAL_SCR_SYNTAX) @ script [shell input], line 1, column 2: Unexpected, comma at end, of list, > > a small handful of cases optionally treat a newline as a semicolon, but > those are well-defined (and documented). All ()/[]/{} constructs, from the > (sub-(sub-))parser's view, end in an EOF, which implicitly acts like a > semicolon. > > It isn’t as simple as “} = EOX”. It is actually, because of how the parser works. ALL block constructs are parsed as if the parser only sees the internals of those constructs. They don't even see the outer braces. > "line": 13, > "message": "Unexpected consecutive non-operators: #3024 > (KeywordFunction) ==> #1010 (Identifier)", > Two expressions next to each other. That's what it's intended to do. > So, apparently “return” triggers EOX, but a subsequent “var” does not? > It’s confusing. > s2's keywords do _not_ behave like most languages. Keywords evaluate to values in s2. i don't know of any other language which does that (but there likely are a few). Because of that, this is legal: var f = proc( x = for( var i = 0; i < 10; ++i ) {i>4 && break i}, y = scope { var a = [ 1,2, 3]; a[2] } ){ assert 5 === i; assert 3 === y; }; f(); > > > Is there a way to type such an example into the REPL without putting > it all on a single line? > > > > i don't know what you mean by REPL. > > Read Eval Print Loop. It’s a generic term for any interactive language > interpreter. > > https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop > > It’s a way to distinguish s2-the-language from > s2-the-interactive-interpreter with fewer characters. I could have written > f-s2sh, but REPL is still shorter, and it’s in my muscle memory. > Aha - i've learned a new term. > What I’m saying is that if I type > > var obj = { > > into the REPL, it should realize that there is an unmatched { and go back > and get another line from the user, with the expectation that the matching > } will appear later. > Nope - the shell is stupidly syntax-unaware. It feeds only single input lines to the engine. IF the underlying readline impl supports multiline input, GREAT. If not, bummer. > In f-s2sh’s case, you’d parse until you got EOX instead, whether that’s a > semicolon or a bracket character. > The shell knows literally nothing about the syntax, so it doesn't have enough info to try that type of thing. It only knows how to tell the engine "execute this for me" and to handle the result value (if any). -- ----- 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
