Don't be silly, it always was possible to build Kernel modules, you could
always use `--gc:none` and `importc` `kalloc` and write C style code in Nim
with `cast` and `ptr`. Now with `--gc:arc` it's more convenient than ever but
it always was possible. You also likely want to use `--compileOnly`
The problem was that the AsyncProcess waitForExit() callback was not closing
AsyncFd. (This is not a problem with Nim compiler/library itself, my apologies).
Well, on behalf of my research about it on internet it is not possible to
directly write Linux kernel modules in Nim without modifying or "hacking" the
Nim compiler. Till now Nim programming language didn't have official help for
piece level programming or producing Linux bit modules. Thanks
please make a pull request
the examples in the docs does no convenience me, why not use a template?
instead of
template optMul{`*`(a, 2)}(a: int): int = a+a
Run
just write:
template `*`(a: int, b: static[2]): int = a+a
Run
I prefer: Nim ⋈ Ninja ==> Nimja
Hi All,
I'm interested in using Nim for corporate use. Everything looks great
technically speaking, but what's the organizational structure? Is their a Nim
foundation? How old is Andreas? Are the financials of the organization
sufficient at this time?
If there's already an article addressing t
Yh, NimConf 2023! 🥳
I prefer Nimster.
I'd love more loose license here as well, CC-BY-SA is great.
It may be silly case, but my friend is doing tarot deck out of programming
languages as a way of embracing both crafts (we are both fascinated by
esotericism and programming) and making this as sort-of fan art project that
could be sh
I have been using this for my upcoming talk "Malebolgia - Structured
concurrency for Nim" but unfortunately the conference got delayed by a couple
of months. But hey, there is NimConf 2023... Right?
Sorry, my bad. Please disregard my comments about sdl2.
So we need to decide which low-level API for window/events is to be used - sdl2
(which nimx uses) or glfw (which fidget uses).
It's not an "elephant", it's an ant. Impaired users can always demand fixes.
The elephant in the room is accessibility, and using native toolkits sometimes
allows sidestepping the issue. Shoulders of giants and all that.
> This precludes sdl2, which uses a polling (i.e. queued) event mechanism.
What do you mean? I have written an immediate mode UI on top of SDL2 and so
have many others. On the contrary, SDL2 is a prime example of how event
handling can easily serve both cases.
>From the discussion so far it seems to me that a few conclusions that can be
>reached, and that there are existing packages that can be used, or enhanced,
>or stolen from (nimmed?), to give us a good start on implementation:
* The need to accommodate both "retained" (queued with polling) and
> > Companies want to brand their UI/UX.
>
> Let them build their own UI frameworks paying their own money.
Seconded. Having different applications use the same UI components makes
desktop use less distracting and even less tiring. Also this allow customizing
the whole desktop consistently, e.g
Yeah, let us be tolerant - but only if it doesn't offend me.
All true, so we shall call us Nimmasters.
In this day and age it's only virtuous to stand up and fight the
(mis)appropriation of a noble name Nimrod by a certain culture and use it
proudly.
[Transport Layer](https://forum.nim-lang.org/postActivity.xml) is replaceable,
currently simple HTTP server used, I want to keep Mono core simple. It could be
changed to different protocol, like WebSockets, with specific auth, and session
management strategies, etc.
Very nice! How is the browser receiving events? Is there a polling loop or is
it using websockets?
Thanks! So you too have to do DOM diffing but you do it server-side, got it.
Amazing, I wonder if Karax (or a fork of it) should do the same.
Thanks. The whole framework is basically one server function
`session.process(events: seq[InEvent]): seq[OutEvent]`, it works as follows:
* Browser listens to UI events and sends it to server as InEvent.
* Server session maintains UI tree, and listens for events. And when get
event - updates
Most impressive! But how does it work?
> Wow, almost as if I thought a little bit about it before posting. :P
I was thinking more on the lines of being compatible with NimScript. Being in a
dll is not a sufficient condition, NimScript is ;)
> One of the famous last words. My favorite battle-cry.
The only _real_ difference is `while true: awaitEvent(ev); process(ev); draw()`
and `while true: if peekEvent(ev): process(ev); draw()`.
Whether widgets own the data they render or not is orthogonal to this and
likewise how much state is k
> it's rather easy to accomplish
One of the famous last words. My favorite battle-cry. :)
> "Works well for boring apps and for games"
Then we don't need both approaches. Having both would be very nice, just not a
top priority.
I saw games which were using QT as GUI framework and professional
# uname -a
Linux myfed 5.6.6-300.fc32.x86_64 #1 SMP Tue Apr 21 13:44:19 UTC 2020 x86_64
x86_64 x86_64 GNU/Linux # date -R Thu, 29 Jun 2023 00:56:04 -0700
# cat test3.nim
import times
proc laTzInfo(time: Time): ZonedTime =
ZonedTime(utcOffset: 25200, isDst: false, time: time)
let laZone =
nimiSlides v0.2.3 has been released! It contains multiple quality of life
changes as well as the first steps towards a proper documentation. You can see
the API docs [here](https://hugogranstrom.com/nimiSlides/docs/nimiSlides.html).
And I have spent time writing tutorials for most of the feature
30 matches
Mail list logo
