On Feb 18, 2016, at 7:25 PM, Stephan Beal <sgb...@googlemail.com> wrote: > > On Fri, Feb 19, 2016 at 2:34 AM, Warren Young <w...@etr-usa.com> wrote: > fsl_utf8.c:182:10: error: incompatible integer to pointer conversion assigning > to 'char *' from 'int' [-Werror,-Wint-conversion] > zOut = fossil_strdup(zFilename); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~ > > i don't get those with clang on my box: > > make CC=clang > …
It must be a bitness or integer/pointer size difference between OS X and Linux, then. I can’t chase it now, though. > try: > > ./configure --loud > > to see "loud" builds. I’ll pencil that into my schedule. > "_iconv_open", referenced from: > _fsl_filename_to_utf8 in fsl_utf8.o > > iconv is Apple, about which i know nothing. 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. > > 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. > $ install_name_tool -change libfossil.so \ > @executable_path/../libfossil.so f-s2sh > > eeek - i have tried to avoid anything more platform-specific than straight > compiling and linking. That said, i rarely say no to patches. 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. Should I send patches here, direct to you, or…? I haven’t done copyright assignment with drh yet, for what that’s worth. All of my Fossil patches have been minor things. > 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. “Here, try this and post the output” and such. It would sit between the two current options for debugging Fossil, SQL commands (often too high level, and only sees static state besides) and running fossil under a debugger (sees dynamic state, but often way too low level). > 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”. 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. > > 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. Saying RTFM here is like explaining away a semantic difference in “else if”. 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. 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; }; var obj = MyClass(1, 2); obj.method(); That’s more in keeping 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. 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. 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. > Speaking of: the manual hit 150 pages something this evening. Yes, which is why I only skimmed it. :) > 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”. Take my factory function example above. There are two “var thing = { … }” constructs, both of which I give with a semicolon for consistency, but one is optional and the other not. Why the difference? Removing the semicolon on the outer one (var MyClass = …) results in: rc=105 (CWAL_RC_EXCEPTION) EXCEPTION: exception@0x7f9c515003a0[scope=#1@0x7fff4fec1ec8 ref#=0] ==> { "code": 2009, "column": 2, "line": 13, "message": "Unexpected consecutive non-operators: #3024 (KeywordFunction) ==> #1010 (Identifier)", "script": "factory.s2", "stackTrace": [{ "column": 19, "line": 1, "script": "shell input" }] } So, apparently “return” triggers EOX, but a subsequent “var” does not? It’s confusing. > > 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. 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. You can see this in sqlite3, for example. Until you give the ; terminating the query, you just get a prompt for another line. In f-s2sh’s case, you’d parse until you got EOX instead, whether that’s a semicolon or a bracket character. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
