P.S.
"I need real-time responses when playing chess across the internet"
Since this is a chess _client_ that displays moves received via the internet,
it's hard to see how you "need" such a thing, since the user won't be able to
discern whether a delay is caused by the GC or by network traffic
That's awesome dude!
I wish I can help but thanks for exposing this concept to me! :)
I don't think you understand what "real-time responses ... across the internet"
means. The timing of a chess interface is measured by human perception, which
is a much longer time than what real-time systems require.
What is the maximum delay that your system can tolerate, and what do you think
Why is this an "utterly bizarre requirement"? I need real-time responses when
playing chess across the internet; and on another project I need the same
response for robotics work. Having a GC implies the "threat" of the app pausing
execution to do GC.
Regarding, (2) simply compile with --gc:arc. (Not to mention what an utterly
bizzare requirement that is...)
I am creating a chess interface client for the Internet Chess Club server
hosted on Ubuntu Linux using the Nim ecosystem.
Since I'm new to Nim, I'd like feedback on what libraries to use for my
requirements. These are the requirements:
1- TCP/IP client connection to server
2- No GC being used
I'm not an expert on the internals of Nim; and while I had quite a bit of
experience with C back in the '80s. I'm not going to claim to be a C internals
expert either. In some of my current "pooling" libraries I've been making
various assumptions but without much context, so I'm not sure I've ma
Thanks I will.
Giving a final update here for those that may want to use the code above, don't
trust the results. I've just tested this against a web crawler I've been using
for quite a while now and in many cases there's still a breakage, leaving some
results out.
Until the parser can repair
Rolling out my ecs lib on Nim ,
[https://github.com/PixeyeHQ/pixecs](https://github.com/PixeyeHQ/pixecs)
I used some macro for removing boilerplate stuff that is very common to many
ecs approaches on other langs. Thanks to Nim it was easy. HUUGE thanks to
@thenjip , @cblake, @doofenstein, @dawk
Ah, this explains why gintro has been packaged into Parrot:
[https://repology.org/project/gintro/versions](https://repology.org/project/gintro/versions)
This is among the first handful of Nim libraries to reach OSes, together with
some packages in Debian. I'll try to package gintro as well.
Maybe named tuples if they fit your case.
const
table = (
key1: (param1: "a string", param2: 100),
key2: (param1: "another string", param2: 200)
)
echo table.key1.param1 # a string
Run
> sets : what are they
@jseb
I hope you have not already retired?
I have yesterday extended the sets section, it was indeed not detailed enough
before:
[http://ssalewski.de/nimprogramming.html#_sets](http://ssalewski.de/nimprogramming.html#_sets)
There are some typos left, I may do proofreadi
moigagoo: my bad! should be working now
Salient: excited to see you there!
Yes, but there is a codegen bug we need to fix. The bug is a decade old
though...
I expect this will be detected at compile-time once we have the Z3 theorem
prover:
type
DocKind = enum
text,
todo
Doc = object
case kind: DocKind
of text:
text: string
of todo:
todo: string
let do
Does this still hold with ARC?
> Is there an alternative or recommendation so that I know a random Google
> Search won't break?
Please report a bug with an example HTML string inside.
First of all, big fan of yours Araq.
The goal here is to eventually add this crawler as a feature in a commercial
product. Is there an alternative or recommendation so that I know a random
Google Search won't break?
Getting the correct search results and in the correct order is priority #1 when
19 matches
Mail list logo
