I'd like to be able to re-run CI just for what needs to be re-run without
having to re-run everything to save CI cycles.
this works fine for sr.ht (if you have an account), and for github actions
(when it fails, IIRC you can rerun at least if project member), but somehow not
for azure
One of the things that intrigued me about Nim was it's object system, you could
create value, reference and pointer types with/without inheritance. As I
understand it, an important distinction between ptr and ref classes is that ref
classes are managed by the garbage collector while ptr classes
> need to define your destructor earlier
Yes, my initial guess was indeed that, as it was done in that way in the
earlier gintro code.
But I became unsure if it would work really fine also that way.
And it remains strange, as my fnew template should fully hide the use of the
finalizer when we
nimatic
`import json, algorithm let j = parseJson"""[{"id":"5","name":"A"},
{"id":"6","name":"C"}, {"id":"3","name":"B"}]""" let x = j.getElems.sorted(proc
(a, b: JsonNode): int = cmp(a["name"].getStr, b["name"].getStr)) echo x #
@[{"id": "5", "name": "A"}, {"id": "3", "name": "B"}, {"id": "6", "name":
Yes, there is definitely room for improvements. I just wanted to check if using
bigints with minimal changes would be working. And I am actually surprised it
does, since I was not able to find a gcd prox overloaded for BigInt (I was
expecting to have to provide an implementation). Not sure what
I know why it doesn't compile but my reply would be identical to the compiler's
error message. You need to define your destructor earlier, like so:
when defined(gcDestructors):
proc `=destroy`*(self: var typeof(Event()[])) =
if not self.ignoreFinalizer and self.impl !=
You need to use in-place addition and multiplication instead of out-of-place
otherwise you will bottleneck on memory allocation/deallocation during all
those loops with nim-bigint.
If it fits in an uint64, stint is not needed, but otherwise as it's all stack
allocated you won't suffer from
The allure of undocumented behaviors ;)
@dataPulverizer, if you already use pointers you can use generic procs, why do
you need inheritance for dispatch?
OK, first of all I am very new to Nim. I have JSON data that I am retrieving
via a REST API and I want to sort it based on a field in that data. The data
looks something like this:
[{"id":"582090251837636960","name":"Company
> you can't mix inheritance with un-managed raw pointers.
I can do it. In fact, I did in Nim's allocator.
> you can't mix inheritance with un-managed raw pointers.
I can do it. In fact, I did in Nim's allocator.
I was just working a bit on gintro for latest GTK4 and got a really confusing
error message.
Luckely I was just able to generate a minimal example, but I have still no real
idea what the problem may be. I guess there must be something special in this
code, because I have used similar
Isn't the point of inheritance method dispatch? Why isn't that a separate issue
from objects that are dissociated from the garbage collector?
Hi, out of curiosity I decided to do a naive "port" of the algorithm to use
[https://github.com/def-/nim-bigints](https://github.com/def-/nim-bigints)
Apart from the fact that doing that I ran into an issue with bigints
Hey guys,
a few days ago I've released version 0.9.3. In this version I'm using now glade
and binding signals automatically. The source code and project structure is
still not clean, because I never inteded to create a unlock gui (so please
forgive me ;) ). The project will be delivered in the
> you can't mix inheritance with un-managed raw pointers
That is an interesting point, I was wondering about it this morning already
when I wrote my first reply.
I am still not sure. I could generally imagine that inheritance can work with
with un-managed raw pointers. But maybe not in Nim?
For all changes in the latest devel (that's the development branch) you can
read
[https://github.com/nim-lang/Nim/blob/devel/changelog.md](https://github.com/nim-lang/Nim/blob/devel/changelog.md)
`ptr object of RootObj` seems very strange, you can't mix inheritance with
un-managed raw pointers.
I’ve been using Nim 1.2 so far, because it’s what Homebrew poured me, and
because I figured it’s best to start with a stable release.
But a lot of devs seem to use 1.3.x ... and I’m curious what new goodies it
has. But I can’t find release notes or a what’s-new list anywhere. Is there
such a
Browsers have _always_ supported “tag soup” HTML, back to Mosaic and Netscape.
Unless the content type is XHTML, you cannot expect any sort of valid
structure. For parsing “wild” HTML, preprocessing through some widely-used
tidier is probably the best bet, since its interpretation of bad markup
I wasn’t aware of that book, though I’ve been guzzling from the
Nim-documentation firehose for a week now. You should get it linked from the
Nim-lang “learning” page!
In the last answer, the git shows how to make a console on the fly, and the
possibility of executing a program in this console, basically this is what I do
with termVte (in the example it is frozen but it was for my tests)
We can already do italics and bold via * though, so it really isn't so bad.
What is more annoying is the inability to respond with just a code block, those
are bugs that need to be fixed.
Thanks, except for those bold/italics, other rendering (especially the Markdown
link syntax) is nicely supported in the newer nimforum version:
[https://forum.my-toolbox.xyz/t/6](https://forum.my-toolbox.xyz/t/6)
> Instead of having multiple small macros that don't play well together and
> have only a local context, I'll apply a visitor-like pattern and I can
> control the scopes in the DSL.
Yes! Now you're cooking.
I think more things will work after a redeploy of nimforum. :-)
Testing quote block:
> some quote
echo "hello"
Run
_[Italics](https://forum.nim-lang.org/postActivity.xml#italics)
**Bold**
_ **Bold and italics** _
[Nim website]([https://nim-lang.org](https://nim-lang.org))
## heading level 2
## heading level 3
>From
>[https://github.com/mratsim/number-theory/blob/12c54a7476327cf9ab00989c9964732e3eb68be7/src/modular_arithmetic.nim](https://github.com/mratsim/number-theory/blob/12c54a7476327cf9ab00989c9964732e3eb68be7/src/modular_arithmetic.nim)
Modular addition
proc addmod*[T:
Night has been enlightening. I understand my error. Instead of having multiple
macros `algo1`, `evaluate`, etc. that are called when Nim compiler evaluates
the syntax tree from the `dsl```call, I must see ``dsl` as a compiler itself.
Now, I have only one macro, `dsl`, that is used to convert
> As far as I can see one of the issues if that there's an overflow when two
> big uint64's are multiplied.
Since after the multiplication you're taking a modulo, [these examples of
modular
arithmetic](https://en.wikipedia.org/wiki/Modular_arithmetic#Example_implementations)
might come
> Unfortunately that is a bug that is very hard to solve
Ok, but the workaround is trivial, no? Just use `nimpy.callMethod` directly
instead of the `.()` magic.
Uh wouldn't have guessed it would be such a complex issue actually.
Well, thanks for the heads up, i'll just use non-generic proc.
`world` must be a parameter of your internal "closure".
Either you use `{.closure.}` and when the compiler sees that `world` is capture
from the external context it will allocate a copy on the heap.
Or you use `{.nimcall.}` or `{.cdecl.}` and all the values captured must have a
infinite
If there's a pattern of doing init(...), evaluate: ..., let ... = getValue(),
then you can convert it to something like this:
dsl:
algo1 as x:
echo x
algo2(x) as y:
echo y
Run
I am trying to define the following callback from Nim:
static void nearCallback (void *data, dGeomID o1, dGeomID o2)
{
int i;
//-- Get the body's ID
dBodyID b1 = dGeomGetBody(o1);
dBodyID b2 = dGeomGetBody(o2);
//-- If they are
> That would be awesome ! Is there a way to call numpy API directly in
> arraymancer or do you still use Nimpy ?
No there is nothing for now.
After further investigation it's not a name conflict issue.
This compiles
import ../src/arraymancer
import nimpy
import nimpy/raw_buffers
import sequtils
proc `+`[T](p: ptr T, val: int) : ptr T {.inline.}=
cast[ptr T](cast[uint](p) + cast[uint](val *
Hello! So I decided to start trying to implement MTProto protocol (Telegram) in
Nim, did the most basic things so I can get a reply from the server for the
first time.
To continue I need to decompose a number `pq` into two prime cofactors `p` and
`q`, such as `p` < `q`. So basically I need to
I just wasn't sure whether when allocating for objects you have to account for
any "gubbings", just cautious I guess:
type
MyTypeA = ptr object of RootObj
x: int64
MyTypeB = ptr object of RootObj
x: array[0..4, int64]
var x0 =
Ok, technically reason is not GC per se, but thread-local values cannot be
accessed from other threads. Also, when cache is full, new items will overwrite
old items (idea of FIFO ring buffer) and then they will be garbage collected.
Here's a very simplified example that will cause SIGSEGV:
I must admit that originally I wrote it this way by mistake. There goes my
short-lived reputation as "the guy who invents really interesting AST hacks"...
But the syntax stuck. In this rare occasion, it not only looks cool, it
improves readability. Likely/unlikely is not an ordinary procedure
42 matches
Mail list logo
