Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Warren Young]

On Feb 19, 2016, at 9:04 PM, Andy Bradford  wrote:
> 
> Notice here that my stack has much smaller numbers pTarget=0xcf7c6300 vs
> pTarget=0x7fffaf5dccd0:

I’m on a 64-bit machine.  If yours OS or executable is 32-bit, that explains it.

Also, different OSes use different defaults in how they present the address 
space to applications.
___
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] ./src/delta.c:231: checksum: Assertion failed

[Andy Bradford]

Thus said Stephan Beal on Sat, 20 Feb 2016 04:46:51 +0100:

> i  see lots  of 0x7ffs  in there,  and i  happen to  know that
> se=... is  indeed a stack-allocated  object. i'm a bit  surprised that
> argv is, but not overly so.

Yeah, I guess it's  more common than I thought and I'm  not used to such
big stack values.

$ echo 16i7FFFE330p | dc
140737488347952

Notice here that my stack has much smaller numbers pTarget=0xcf7c6300 vs
pTarget=0x7fffaf5dccd0:

Breakpoint 4, blob_delta_create (pOriginal=0xcf7c6318, pTarget=0xcf7c6300, 
pDelta=0xcf7c6330) at deltacmd.c:28
28  int blob_delta_create(Blob *pOriginal, Blob *pTarget, Blob *pDelta){
(gdb) bt
#0  blob_delta_create (pOriginal=0xcf7c6318, pTarget=0xcf7c6300, 
pDelta=0xcf7c6330) at deltacmd.c:28
#1  0x146000c0 in stash_add_file_or_dir (stashid=1, vid=Variable "vid" is not 
available.
) at stash.c:126
#2  0x146002dc in stash_create () at stash.c:195
#3  0x14600a3a in stash_cmd () at stash.c:499
#4  0x145d48c9 in main (argc=5, argv=0xcf7c66b4) at main.c:804

Sorry for wasting everyone's time, I  just noticed that there was a huge
difference in  what the OP reported  and what I was  seeing, but clearly
there  are some  architectural differences  that  lead to  a huge  stack
address  in some  cases and  I wondered  if somehow  the addresses  were
wrong---case ignored. :-)

Thanks,

Andy
-- 
TAI64 timestamp: 400056c7e5e7


___
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] ./src/delta.c:231: checksum: Assertion failed

[Stephan Beal]

On Sat, Feb 20, 2016 at 4:42 AM, Andy Bradford 
wrote:

> Thus said Martin Gagnon on Fri, 19 Feb 2016 20:56:47 -0500:
>
> > This is not usually stack addresses?
>
> Yes, for  allocated memory, but  how big is  the stack that  supports an
> address that big?
>


Dunno. Just kinda randomly taking a backtrace from a random program...

#0  0x776b6810 in __read_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1  0x779b9a7d in rl_getc () from
/lib/x86_64-linux-gnu/libreadline.so.6
#2  0x779ba2ae in rl_read_key () from
/lib/x86_64-linux-gnu/libreadline.so.6
#3  0x779a3edc in readline_internal_char () from
/lib/x86_64-linux-gnu/libreadline.so.6
#4  0x779a4625 in readline () from
/lib/x86_64-linux-gnu/libreadline.so.6
#5  0x0040c4a8 in s2sh_line_read (prompt=0x48051d "s2> ") at
shell.c:636
#6  0x0040cc8d in s2sh_interactive (se=0x7fffcfb0) at
shell.c:842
#7  0x0040d217 in s2sh_main2 (se=0x7fffcfb0) at shell.c:1021
#8  0x0040d933 in s2sh_main (argc=1, argv=0x7fffdb78) at
shell.c:1157
#9  0x0040eaaf in main (argc=1, argv=0x7fffdb78) at shell.c:1555

i see lots of 0x7ffs in there, and i happen to know that se=... is
indeed a stack-allocated object. i'm a bit surprised that argv is, but not
overly so.

-- 
- 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] ./src/delta.c:231: checksum: Assertion failed

[Andy Bradford]

Thus said Martin Gagnon on Fri, 19 Feb 2016 20:56:47 -0500:

> This is not usually stack addresses?

Yes, for  allocated memory, but  how big is  the stack that  supports an
address that big?

Andy
-- 
TAI64 timestamp: 400056c7e0c0


___
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] ./src/delta.c:231: checksum: Assertion failed

[Stephan Beal]

On Sat, Feb 20, 2016 at 2:53 AM, Andy Bradford 
wrote:

> Thus said Warren Young on Fri, 12 Feb 2016 09:45:34 -0700:
>
> > #5  0x004237f6 in blob_delta_create (pOriginal= out>, pTarget=0x7fffe330, pDelta=0x7fffe370) at ./src/deltacmd.c:40
>
> I could be wrong, but those seem like extreme memory addresses...
>
> Anyone?
>

Stack-allocated. All buffers are.



-- 
- 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] ./src/delta.c:231: checksum: Assertion failed

[Martin Gagnon]

> Le 19 févr. 2016 à 20:53, Andy Bradford  a écrit :
> 
> Thus said Warren Young on Fri, 12 Feb 2016 09:45:34 -0700:
> 
>> #5  0x004237f6 in blob_delta_create (pOriginal=> out>, pTarget=0x7fffe330, pDelta=0x7fffe370) at ./src/deltacmd.c:40
> 
> I could be wrong, but those seem like extreme memory addresses...
> 
> Anyone?
> 

This is not usually stack addresses?

-- 
Martin G.
___
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] ./src/delta.c:231: checksum: Assertion failed

[Andy Bradford]

Thus said Warren Young on Fri, 12 Feb 2016 09:45:34 -0700:

> #5  0x004237f6 in blob_delta_create (pOriginal=, 
> pTarget=0x7fffe330, pDelta=0x7fffe370) at ./src/deltacmd.c:40

I could be wrong, but those seem like extreme memory addresses...

Anyone?

Andy
--
TAI64 timestamp: 400056c7c72c
___
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] fossil all remove?

[Ross Berteig]

On 2/19/2016 4:51 PM, Richard Hipp wrote:

On 2/19/16, Warren Young  wrote:
Again, I think the cleanup should be automatic.  But if you are still
having trouble the "fossil all ignore DIRECTORY" command should
manually remove the offending check-out from the list.  Maybe the "-c"
option is also needed - unclear.


This reminded me to look, and my recent obsession with the test suite 
has littered my fossil all list output with all the places I ran the 
tests. Which leads to two observations:


1. I thought I saw code in tester.tcl to prevent that... either I was 
misreading, or it doesn't work for me on Windows. Both are likely. I'll 
take a look at that "real soon now".


2. fossil all ignore only works for precisely named repositories, or 
with the -c option for named directories that are open workspaces. It 
would be nice if a path prefix could be used. Specifically, I was hoping 
that


C:> fossil all ignore C:\Users\Ross\Tmp\fbuild

would ignore the dozen repositories (and checkouts if repeated with -c) 
located below that path, since that folder is an out-of-tree build of 
fossil where I ran the test suite. I have several more folders just like 
it (built with different configurations).


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/

___
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] Scripting fossil

[Scott Robison]

On Fri, Feb 19, 2016 at 4:55 PM, Warren Young  wrote:

> On Feb 18, 2016, at 7:20 PM, Scott Robison 
> wrote:
> >
> > As it turns out, this wasn't a great plan.
>
> I agree.  I even dislike checking configure scripts generated by autoconf
> and similar into repos.
>
> (Please, hold the replies.  I already know the justifications.  I just
> don’t agree.)
>
> > Since I'm using Windows, I was inclined to just use a batch file
>
> *wince*
>
> I wonder if it would be cleaner in Stephan Beal’s f-s2sh language?
>

It would have been cleaner in just about anything. But there was a
principle involved, namely bending Windows to my will.

Note: I have cygwin installed on my machine, so it's not like I couldn't
have used another more posixy tool. But this worked adequately for me.


> > fossil update next
>
> That’s worth reading this post all by itself.  I knew about most of the
> other special tags, but not that one.  Thanks!
>
> I assume “next” ignores branches, so that rewriting the repo by stepping
> through it with “next” in a loop will prune all the branches?
>

I would assume so, but don't know as I had no branches in this repo and no
repo with branches from which I wanted to excise any history.

This was a pretty special case. :)
-- 
Scott Robison
___
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] fossil all remove?

[Richard Hipp]

On 2/19/16, Warren Young  wrote:
> On Feb 19, 2016, at 3:06 AM, Tino Lange 
> wrote:
>>
>> How can I get rid of an entry in "fossil all ls -c" for which the
>> checkout does not exist anymore? Do I need to fiddle with SQL?
>
> I think this happens when you nuke a fossil checkout (e.g. via rm -rf)
> without saying “fossil close” first.
>
> It used to happen to me with temporary and test repo checkouts until I got
> into the habit of saying “fossil close” on them before nuking them.

Again, I think the cleanup should be automatic.  But if you are still
having trouble the "fossil all ignore DIRECTORY" command should
manually remove the offending check-out from the list.  Maybe the "-c"
option is also needed - unclear.

-- 
D. Richard Hipp
d...@sqlite.org
___
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] repo sharding (was: libfossil scripting mini-demo)

[Stephan Beal]

On Sat, Feb 20, 2016 at 12:51 AM, Warren Young  wrote:

> On Feb 18, 2016, at 8:56 AM, Stephan Beal  wrote:
> >
> > s2> var m = c.loadManifest('current');;
> >
> > s2> foreach(m=>k) print(k)
>
> I wonder, would it be practical to use f-s2sh for repository sharding?
>
> That is, I want to take a single long-lived repo holding several projects
> and break it up into project-specific repos, each holding only the
> artifacts relevant to that particular project.
>
> Each project is strictly confined to a top-level directory in the repo, so
> selecting the relevant artifacts wouldn’t be difficult.  It should even be
> easy to drop that extra directory level in the output repo, so that
> prj/path/to/file.cpp becomes path/to/file.cpp in the new prj.fossil repo.
>

Interestingly...

one of the benefits of having the library API is that we can experiment
with such things without breaking/relying on the core app. Some of Fossil's
SCM features can be used without the others, e.g. delta and diff generation
and application. Those work at a level which is independent of manifests
and such, and could hypothetically be used for constructing one's own SCM
features.


> I’d hoped bundles could do this, but even with --standalone, you don’t get
> a repo that can stand on its own.
>

i don't _think_ fossil's model can support that, but i've been known to be
wrong about such things.


-- 
- 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] Scripting fossil

[Warren Young]

On Feb 18, 2016, at 7:20 PM, Scott Robison  wrote:
> 
> As it turns out, this wasn't a great plan.

I agree.  I even dislike checking configure scripts generated by autoconf and 
similar into repos.

(Please, hold the replies.  I already know the justifications.  I just don’t 
agree.)

> Since I'm using Windows, I was inclined to just use a batch file

*wince*

I wonder if it would be cleaner in Stephan Beal’s f-s2sh language?

> fossil update next

That’s worth reading this post all by itself.  I knew about most of the other 
special tags, but not that one.  Thanks!

I assume “next” ignores branches, so that rewriting the repo by stepping 
through it with “next” in a loop will prune all the branches?

Reference for the rest of the special tag names:

  
http://fossil-scm.org/index.html/doc/cd58f59a474c7ef773d1/www/checkin_names.wiki

> I wanted to document it in case it was useful for someone else

It was.  Thanks again!
___
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] libfossil scripting mini-demo

[Stephan Beal]

On Sat, Feb 20, 2016 at 12:25 AM, Warren Young  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 
> #include 
> #include 
>
> int main(void)
> {
> struct termios tp;
> if (tcgetattr(STDIN_FILENO, ) == 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.")

Re: [fossil-users] repo sharding (was: libfossil scripting mini-demo)

[Warren Young]

On Feb 18, 2016, at 8:56 AM, Stephan Beal  wrote:
> 
> s2> var m = c.loadManifest('current');;
> 
> s2> foreach(m=>k) print(k)

I wonder, would it be practical to use f-s2sh for repository sharding?

That is, I want to take a single long-lived repo holding several projects and 
break it up into project-specific repos, each holding only the artifacts 
relevant to that particular project.

Each project is strictly confined to a top-level directory in the repo, so 
selecting the relevant artifacts wouldn’t be difficult.  It should even be easy 
to drop that extra directory level in the output repo, so that 
prj/path/to/file.cpp becomes path/to/file.cpp in the new prj.fossil repo.

I suspect the tricky part is tracing branches correctly, so that the output 
repo’s structure is an exact subset of the input repo.

I’d hoped bundles could do this, but even with --standalone, you don’t get a 
repo that can stand on its own.
___
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] fossil all remove?

[Warren Young]

On Feb 19, 2016, at 3:06 AM, Tino Lange  wrote:
> 
> How can I get rid of an entry in "fossil all ls -c" for which the 
> checkout does not exist anymore? Do I need to fiddle with SQL?

I think this happens when you nuke a fossil checkout (e.g. via rm -rf) without 
saying “fossil close” first.

It used to happen to me with temporary and test repo checkouts until I got into 
the habit of saying “fossil close” on them before nuking them.
___
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] libfossil scripting mini-demo

[Warren Young]

On Feb 18, 2016, at 7:25 PM, Stephan Beal  wrote:
> 
> On Fri, Feb 19, 2016 at 2:34 AM, Warren Young  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 
#include 
#include 

int main(void)
{
struct termios tp;
if (tcgetattr(STDIN_FILENO, ) == 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 

Re: [fossil-users] fossil all remove?

[Tino Lange]

> Should be automatic.  When you do "fossil all ls -c", Fossil checks that
> each of the check-out directories exists, and removes any that do not
> exist from the list.

Thanks. The directory still exists (but with some other content now, 
especially it has no .fslckout file)

So I'll move it away, do a "fossil all ls -c" and move it afterwards back 
to its location :-)

___
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] fossil all remove?

[Stephan Beal]

On Fri, Feb 19, 2016 at 11:06 AM, Tino Lange  wrote:

> Hi Fossilers,
>
> There is no "fossil all remove".
> How can I get rid of an entry in "fossil all ls -c" for which the
> checkout does not exist anymore? Do I need to fiddle with SQL?
>

Fossil all recognizes when it sees a non-existing checkout and removes it
from its list. Or it did the last time i looked at that code. (Or that's
how i remember it, anyway!)

  /* If any repositories whose names appear in the ~/.fossil file could not
  ** be found, remove those names from the ~/.fossil file.
  */
  if( nToDel>0 ){
const char *zSql = "DELETE FROM global_config WHERE name IN toDel";
if( dryRunFlag ){
  fossil_print("%s\n", zSql);
}else{
  db_multi_exec("%s", zSql /*safe-for-%s*/ );
}
  }


-- 
- 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] fossil all remove?

[Richard Hipp]

On 2/19/16, Tino Lange  wrote:
> Hi Fossilers,
>
> There is no "fossil all remove".
> How can I get rid of an entry in "fossil all ls -c" for which the
> checkout does not exist anymore? Do I need to fiddle with SQL?
>

Should be automatic.  When you do "fossil all ls -c", Fossil checks
that each of the check-out directories exists, and removes any that do
not exist from the list.

Note that it only checks for the existence of the named directories.
It does not try to verify that each directory is in fact a valid
checkout.

-- 
D. Richard Hipp
d...@sqlite.org
___
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 remove?

[Tino Lange]

Hi Fossilers,

There is no "fossil all remove".
How can I get rid of an entry in "fossil all ls -c" for which the 
checkout does not exist anymore? Do I need to fiddle with SQL?

Thanks

Tino

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users