Well, just to add my point to the wish list: unconstrained recursive module
imports
Well, I already mentioned, that the `var` for the source is superfluous for the
example above. There are just some other items within my current research
requiring `var`. Just, for the moment, I am requiring it as a constant reminder
for something else.
Works. Much nicer code, I must admit :-)
OK, will try.
`var` is superfluous - there to allow the wrapperless deepcopy as a default.
Thank you!
Thank you, shirleyquirk for your comments.
Took me a while to get trough them.
Ad `new-style concepts`:
I have not yet looked into this. Is there any documentation (or alike)
available yet? (Tried to find some ...) - Would really like to start using
these rather sooner than later.
Ad `somethi
Dear all,
I am well aware of concepts being experimental. Nevertheless, they have proven
to be quite useful. So, I apply them quite regularly ...
The problem I am currently trying to solve:
I have a 3-layer data structure: (a) a catalogue of matrices, (b) a matrix and
(c) the elements of a mat
> Thanks I've actually learned a bit here too.
Well, my learning curve was somewhat steeper, thank you again. And if I
understood the background sufficiently well, I might have found a reasonable
solution for my issue that involves the lessons learned.
For me, it looks sufficiently foolproof, a
For the sake of completeness:
> Your doParent is odd since it’s calling “parent destroy” twice but not at the
> end.
Had another look at this item. It's because I am using `discard` (& I
shouldn't). Double call at the end is avoided by:
proc doParent() =
var
parent
OK. Good to know. Not a speaker. :-)
Still some chance to register for the conf? - Or simply too late?
Thank you. We did not have an issue with the error messages, though.
The issue is that are using parsesql quite a bit within our code and need to
get threads running. This breaks because we can't get renderSQL gcsafe.
Any idea on how we could get rendersql (resp. parsesql) gcsafe?
11 matches
Mail list logo
