On 18.03.2015 10:36, Branko Čibej wrote:
> On 13.03.2015 13:23, Erik Huelsmann wrote:
>>
>>
>> > These days, I suppose we'd be looking at something like Go,
>> which can
>> > be linked with C/C++ and also natively export functions that can be
>> > called from C/C++.
>>
>> As f
On 13.03.2015 13:23, Erik Huelsmann wrote:
>
>
> > These days, I suppose we'd be looking at something like Go,
> which can
> > be linked with C/C++ and also natively export functions that can be
> > called from C/C++.
>
> As far as I can see, Go always comes with Garbage Colle
> > Heh :-) I meant the branch-specific code -- not *all* of the client and
> > library! I have no idea what that means, because I didn't study the code
> > closely (yet). I'll need some directions on where to look for the
> > branch-specific code so I can try to figure out where to hook Lua in.
>
Erik Huelsmann wrote:
>> > Am I right that if we were to run this experiment with the
>> > move-tracking-2 branch code, that the entire client and library would
>> > be subject to conversion to the higher level language?
>>
>> No! That would be literally years of rewriting and debugging [...]
>
> H
> > Am I right that if we were to run this experiment with the
> > move-tracking-2 branch code, that the entire client and library would
> > be subject to conversion to the higher level language?
>
> No! That would be literally years of rewriting and debugging and
> re-testing, not to mention inter
>> Well, Lua supports calling both ways. A call isn't a straight C call,
>> though (in Lua, it's a straight Lua function invocation), but a call
>> that follows a certain calling protocol. Going from Lua to pure C or
>> pure C to Lua requires a bit of glue code much like sqlite does for
>> its para
On 13.03.2015 15:07, Erik Huelsmann wrote:
>
>
> > @Julian, do you have a specific area of our code that would most
> benefit
> > from "moving 'up' from C"? Preferably some part of code that's
> currently
> > very much in flux?
>
> 'svnmover' on the 'move-tracking-2' branc
> > @Julian, do you have a specific area of our code that would most benefit
> > from "moving 'up' from C"? Preferably some part of code that's currently
> > very much in flux?
>
> 'svnmover' on the 'move-tracking-2' branch. It includes both 'client'
> and 'library' code, and I'm moving code freely
On 13.03.2015 14:18, Ivan Zhakov wrote:
> On 13 March 2015 at 13:43, Branko Čibej wrote:
>> On 13.03.2015 11:13, Ivan Zhakov wrote:
>>> On 13 March 2015 at 12:31, Branko Čibej wrote:
>>> [...]
These days, I suppose we'd be looking at something like Go, which can be
linked with C/C++ and
On 13 March 2015 at 13:43, Branko Čibej wrote:
> On 13.03.2015 11:13, Ivan Zhakov wrote:
>> On 13 March 2015 at 12:31, Branko Čibej wrote:
>> [...]
>>> These days, I suppose we'd be looking at something like Go, which can be
>>> linked with C/C++ and also natively export functions that can be cal
Erik Huelsmann wrote:
>> I don't have direct experience with Lua, but have read/observed it for
>> many years. This is something that I could get behind as an embedded
>> *experimental* solution (to move "up" from lower-level C code), based on
>> what I've read.
>
> That would be the first step for
On 13.03.2015 13:23, Erik Huelsmann wrote:
>
>
> > These days, I suppose we'd be looking at something like Go,
> which can
> > be linked with C/C++ and also natively export functions that can be
> > called from C/C++.
>
> As far as I can see, Go always comes with Garbage Colle
> Hence my suggestion for Lua, which doesn't have a GIL, as far as I can
>> find. Nor does it need manual reference-keeping like is needed with Python
>> or Perl. With Lua you can have as many evaluation environments as you want.
>> Instantiating them when crossing a certain API boundary to be used
> > These days, I suppose we'd be looking at something like Go, which can
> > be linked with C/C++ and also natively export functions that can be
> > called from C/C++.
>
> As far as I can see, Go always comes with Garbage Collection instead of a
> deterministic memory management.
>
> Also, as far
Hi, Erik,
Von: Erik Huelsmann [mailto:ehu...@gmail.com]
>> It would make sense to design type-safe, light-weight container and
>> iterator template wrappers around the APR structures if we decided to
>> write code in C++. Since we're not, "explicit is better than
>> implicit".
> I understand t
On 13.03.2015 11:13, Ivan Zhakov wrote:
> On 13 March 2015 at 12:31, Branko Čibej wrote:
> [...]
>> These days, I suppose we'd be looking at something like Go, which can be
>> linked with C/C++ and also natively export functions that can be called
>> from C/C++.
>>
> After Google Code shutdown we
strictly forbidden.
> -Ursprüngliche Nachricht-
> Gesendet: Freitag, 13. März 2015 10:35
> An: dev@subversion.apache.org
> Betreff: Re: AW: Convenient array & hash iterators & accessors
>
> On 13.03.2015 10:05, Bert Huijben wrote:
> >
> >> -Ori
On Fri, Mar 13, 2015 at 5:08 AM, Erik Huelsmann wrote:
>
>
>> In the past I'd thought about embedding Python into our sources, but
>> Python still (after 20 years ...) depends on a global interpreter lock
>> which pretty much kills any chance of lockless thread-safe code.
>>
>
I've embedded Pyth
On 13 March 2015 at 12:31, Branko Čibej wrote:
[...]
> These days, I suppose we'd be looking at something like Go, which can be
> linked with C/C++ and also natively export functions that can be called
> from C/C++.
>
After Google Code shutdown we have another reason to avoid monoculture
technolog
On Fri, Mar 13, 2015 at 4:31 AM, Branko Čibej wrote:
>...
> >> Why not Groovy (soon to be incubating at the ASF). That way we keep
> >> things in the family, and we're likely to eventually move everything to
> >> a JVM-based implementation instead of this silly native-compiled, last
> >> century
> In the past I'd thought about embedding Python into our sources, but
> Python still (after 20 years ...) depends on a global interpreter lock
> which pretty much kills any chance of lockless thread-safe code.
>
Hence my suggestion for Lua, which doesn't have a GIL, as far as I can
find. Nor doe
On 13.03.2015 10:05, Bert Huijben wrote:
>
>> -Original Message-
>> From: Branko Čibej [mailto:br...@wandisco.com]
>> Sent: vrijdag 13 maart 2015 08:53
>> To: dev@subversion.apache.org
>> Subject: Re: AW: Convenient array & hash iterators & ac
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: vrijdag 13 maart 2015 08:53
> To: dev@subversion.apache.org
> Subject: Re: AW: Convenient array & hash iterators & accessors
>
> On 13.03.2015 08:43, Markus Schaber wrote:
>
> *Von:*Erik Huelsmann [mailto:ehu...@gmail.com]
> *Gesendet:* Freitag, 6. März 2015 22:37
> *An:* Julian Foad
> *Cc:* Branko Čibej; dev@subversion.apache.org
> *Betreff:* Re: Convenient array & hash iterators & accessors
>
>
>
>
>
> > It would make
well thought, strictly
defined subset.
Grüße,
Markus
Von: Erik Huelsmann [mailto:ehu...@gmail.com]
Gesendet: Freitag, 6. März 2015 22:37
An: Julian Foad
Cc: Branko Čibej; dev@subversion.apache.org
Betreff: Re: Convenient array & hash iterators & accessors
> It would make sense to
> > It would make sense to design type-safe, light-weight container and
> > iterator template wrappers around the APR structures if we decided to
> > write code in C++. Since we're not, "explicit is better than
> > implicit".
>
> I understand the point. I note that "explicit" is not a binary qualit
Branko Čibej wrote:
> On 06.03.2015 11:30, Julian Foad wrote:
>> Branko Čibej wrote:
>>> I'm also *very* scared of the implicit, hidden qsort in the sorted.
>>
>> It's invoked only if you write "..._SORTED()" or "..._sorted()". That's
>> explicit and visible. What's so scary about that?
>
> The t
On 06.03.2015 11:30, Julian Foad wrote:
> Branko Čibej wrote:
>> I'm also *very* scared of the
>> implicit, hidden qsort in the sorted.
> It's invoked only if you write "..._SORTED()" or "..._sorted()". That's
> explicit and visible. What's so scary about that?
The term "sorted iteration" is ambi
On 06.03.2015 11:30, Julian Foad wrote:
> Hi, Greg and Brane. Thanks for your feedback.
>
> Branko Čibej wrote:
>> Greg Stein wrote:
>>> We've seen some of this kind of stuff in svn_iter.h, and it did not
>>> turn out to be useful. The additional concepts needed to
>>> learn/keep/use costed more th
Hi, Greg and Brane. Thanks for your feedback.
Branko Čibej wrote:
> Greg Stein wrote:
>> We've seen some of this kind of stuff in svn_iter.h, and it did not
>> turn out to be useful. The additional concepts needed to
>> learn/keep/use costed more than the incremental benefit.
The new functions ar
On 06.03.2015 09:08, Greg Stein wrote:
> We've seen some of this kind of stuff in svn_iter.h, and it did not
> turn out to be useful. The additional concepts needed to
> learn/keep/use costed more than the incremental benefit.
>
> I find the SVN_ITER_T() and SVN_ARRAY_ITER() macros in your example
We've seen some of this kind of stuff in svn_iter.h, and it did not turn
out to be useful. The additional concepts needed to learn/keep/use costed
more than the incremental benefit.
I find the SVN_ITER_T() and SVN_ARRAY_ITER() macros in your example to be
rather inscrutable.
Cheers,
-g
On Thu,
In http://svn.apache.org/r1664127 (very similar to the attached patch),
I added some array & hash iterators & accessors to the 'move-tracking-2' branch
so that I could use more compact iteration code (http://svn.apache.org/r1664285)
and get an iteration pool 'for free' (http://svn.apache.org/r16642
33 matches
Mail list logo
