Re: Is it possible for a macro to know the context it is used?
You could do it by wrapping in a template
import macros
template foo(body: untyped) =
block:
let inFoo {. inject, used .} = true
body
template bar(body: untyped) =
block:
let inBar {. inject, used .} = true
body
proc callApiFromFoo =
echo "Calling API with foo scope"
proc callApiFromBar =
echo "Calling API with bar scope"
template callApi =
when declaredInScope(inFoo):
callApiFromFoo()
elif declaredInScope(inBar):
callApiFromBar()
else:
echo "You can call API only in foo or bar scopes!"
proc foobar =
foo:
callApi()
bar:
callApi()
foobar()
Run
Re: Experimenting with a FreeRTOS OS Port
@araq, that's great! I was hoping to do a PR, but wasn't sure if there would be interest. It seems, LwIP and FreeRTOS support could be split. Most of what I've done is actually port Nim sockets to LwIP. That'd mean it'd be easy to combine Nim & LwIP on many embedded devices. Once I get networking tested I'll create a PR. Would appreciate a code review! There are lots of areas of Nim & FreeRTOS I'm not familiar with. Not really sure how to do the CI, but it'd be great. There is QEMU support for the ESP32.
Re: Revisiting my oldest Nim project.
> I don't think the same issues apply to timestamps the moment you're using FP as your internal internal representation you're affected by FP semantics and the machine epsilon, eg: * catastophic cancellation problem: var a = 1.2 var b = a + 1e14 var c = b - 1e14 echo (a, c, a == c) Run (1.2, 1.203125, false) even with a 10% range of variation you still can't rely on timestamp equality: var a = 0.1 var b = a + 1 var c = b - 1 echo (a, c, a == c) Run (0.1, 0.1001, false) There's a good reason almost all datetime libraries use fixed point/integral arithmetics internally to represent time instead of FP: C (ctime), C++ (std::chrono, boost date_time), mongodb (int64 milliseconds since epoch), D ([https://dlang.org/phobos/std_datetime_systime.html)](https://dlang.org/phobos/std_datetime_systime.html\)), and in particular nim: Time = (secs: int64,nsecs: int) > IMHO that contributes to making the library super awkward to use; you have to > invoke a manual conversion function to cast times to different units. that's a C++ problem; nim doesn't have this problem. Look at the std/times module which abstracts the internal representation as (secs,nsecs) float may be easier on first sight from implementer point of view (not for user point of view), but it just causes more problem. I even added fromUnixFloat+ toUnixFloat in [https://github.com/nim-lang/Nim/pull/13044](https://github.com/nim-lang/Nim/pull/13044) so you can convert your user FP timestamps into internal std/Time (int64,int) representation and then just deal with internal representation for all operations. It gives you nanosecond precision within +/\- 300 billion years, so you can represent any nanosecond in the universe's timespan and well beyond, without any loss or catastrophic cancellation issues, and reliable timestamp equality. # js support for js, BigInt is IMO the right approach; i'ts supported in almost all browsers except for IE (which is EOL'd anyway) and safari (which is "hopefully almost there not giving up hope", see [https://bugs.webkit.org/show_bug.cgi?id=179001](https://bugs.webkit.org/show_bug.cgi?id=179001) which has almost all dependent issues fixed); and there are polyfills eg [https://github.com/peterolson/BigInteger.js](https://github.com/peterolson/BigInteger.js)
Re: Nim Compiler Documentation
compiler docs used to be generated for a short while until [https://github.com/nim-lang/Nim/pull/13509](https://github.com/nim-lang/Nim/pull/13509); a few small things need to be addressed to re-enable compiler docs, which was quite helpful, eg for nim-lang.github.io/Nim/compiler/ast.html (link doesn't work anymore)
Re: proposal: PTAL tag to make it clear that a PR is ready again for review
> > look at my stuff, my stuff is more important than all the other stuff by > > all the other contributors that's not the point at all, quite the opposite. The whole point is for triaging PRs and saving reviewer time by allowing them to filter from those 114 open PR's the ones that are in a ready for review state, without needing to ping anyone / polling so if someone has N open PRs but only 4 of them are ready for 1st/next round of review, meaning: * all comments addressed * no git conflicts * all tests pass except for unrelated failures then the filtering will only show 4 for that user
Re: Is it possible for a macro to know the context it is used?
In other words, is it a part of the job that I can delegate to the Nim compiler semantic parsing phase or it it something I must do before it, when I'm managing the DSL syntax?
Re: Is it possible for a macro to know the context it is used?
I reopen this thread as I'm facing a similar problem, but now when calling an
API.
Is it possible to write a proc whose behaviour is based on existence or not of
macro injected variables? I've tried to reproduce a sample case below:
import macros
template foo(body: untyped) =
block:
let inFoo {. inject, used .} = true
body
template bar(body: untyped) =
block:
let inBar {. inject, used .} = true
body
proc callApi =
if declaredInScope(inFoo):
echo "Calling API with foo scope"
elif declaredInScope(inBar):
echo "Calling API with bar scope"
else:
echo "You can call API only in foo or bar scopes!"
proc foobar =
foo:
callApi()
bar:
callApi()
foobar()
Run
This code **does not give the expected result!**
What I'm trying to do and that does not work: the `callApi` proc takes no
parameters and depend on the scope it is used to call different API entry
points. Its behaviour is really given in the scope it is used. In order to
determine in which scope it is used, I've tried to inject 2 different variables
`inFoo` and `inBar` and base `callApi` behaviour on the presence or absence of
these variables in the scope.
Having changed the way my DSL works, I'm now able to know in which
scope/context the AST is parsed. But in that case, `callApi` is a Nim function
that can be called by the user and I don't want for these types of functions to
have a complex syntax: the user knows if she is using it in the `for` or `bar`
contexts and that's the reason it doesn't have arguments in my example.
Behind the scene, I have two functions `callApiFromFoo` and `calApiFromBar`
with all the parameters required. I want to be able to find which function to
call...
Is the only way to get the expected result to parse the whole AST tree and when
finding a `callApi` call NimNode, replace it with `callApiFromFoo` (resp.
`callApiFromBar`) when in the `foo` (resp. `bar`) scope?
Or is there another way to solve this problem?
Re: Change Nim colour on GitHub
Right now the working colour I found is "#FFDF00", but if you want to propose a different one - you can comment in that PR.
Re: Nim Compiler Documentation
i have not, i will take a look at that now, thank you
Change Nim colour on GitHub
So I always wondered why Nim had the green colour on GitHub and decided to dig up. I found out that the current Nim colour was added in the initial commit which introduced colour support for languages on GitHub - [https://github.com/github/linguist/commit/c3d6fc5af8cf9d67afa572bba363bf0db256a900](https://github.com/github/linguist/commit/c3d6fc5af8cf9d67afa572bba363bf0db256a900). With the PR I want to change the default colour to better match the logo. Any suggestions/discussions are REALLY welcome (but please do the on GitHub) You can check the PR here - [https://github.com/github/linguist/pull/4866](https://github.com/github/linguist/pull/4866). It's still a draft and for that PR to be accepted/changed/rejected we need more community feedback :) If you like the PR - give it a thumbs up, otherwise a thumbs down (that's an easy way to let Linguist maintainers know.
Re: oids library import + Karax --> error
Asking questions here that may or may not be answered in our manuals or tutorials is fine. But short answers are fine too. ;-)
Re: oids library import + Karax --> error
Nono I didn't get offended, but what I understood/read between the lines from your replies is that the answers I'm seeking are in plain sight in Nim manual, which I should've read properly before posting anything here. I feel kinda guilty for wasting your time because I think people who ask trivial questions (before properly trying to find out the answers themselves) should be crusified in all forums. ;)
Re: Experimenting with a FreeRTOS OS Port
I'm _very_ interested in this port and would appreciate PRs. Ideally even CI support.
Re: oids library import + Karax --> error
hey, i don't think anyone was disrespectful towards you here, you might misunderstand the situation. After all text communication lacks emotional cues and its easy get offended.
Re: oids library import + Karax --> error
Yes it helped. Sorry for asking trivialities before really fully understanding the Nim language (eg. before reading the whole manual with a thought). It just seemed a funny way to skip some basics and try to learn the language by building something with karax. I appreciate your answers, I bet you guys have better things to do.
Re: Revisiting my oldest Nim project.
> floats will cause issues with rounding or difference wrt roundtrips, not to > mention stringification I don't think the same issues apply to timestamps. They're not user-visible in raw form, and you're not usually working with adjacent timestamps that are nanoseconds apart, so it doesn't matter if they're off by some tiny epsilon. I like the fact that you never have to worry about overflows. And treeform's point about lack of int64 in JS is important — a lot of JS parsers, in various languages, just parse _any_ number to float64. C++'s std::chrono module does support arbitrary backing types for times (it's a template parameter) but IMHO that contributes to making the library super awkward to use; you have to invoke a manual conversion function to cast times to different units.
Re: Experimenting with a FreeRTOS OS Port
This is great! ESP32 is a nice platform; I've used it a bit in the past, with C++. It'd be good to have Nim running on it. I don't have the time to contribute right now; just offering moral support and thumbs-up 👍🏻
Re: Idea: Nim Online Conference
For me, from this thread and the blog post it always looked like the registration was only for the case that you want to give a talk. So "regular" participants maybe wouldn't look at the form to begin with. That said, I had looked at the form when the conference was announced for June 1st, but not after that. I saw the time in the form back then, but when I then read the conference had been moved to another date, I wouldn't take it for granted that the times stay the same, and therefore I asked. :-)
Re: proposal: PTAL tag to make it clear that a PR is ready again for review
> Please no. +1 > All these title/tag changes are just noise and we've got enough of that > already. +1 > just ping the best person to review that PR Or, better yet, don't ping anybody and just be patient. At the time of writing this, we have 114 open PRs (and that's after two weeks of constant merging as fast as possible! The number was much higher last month.), and it should be obvious to anybody following Nim's github repo that we have very hard time reviewing and merging them in reasonable time. One person pinging and/or PTAL-ing (which already happens), just gives an impression "look at my stuff, my stuff is more important than all the other stuff by all the other contributors". NO! @timothee If you really want to help us with faster merging of PRs, take a look at those 40 out of 114 (35%!) open PRs which are authored by you. Are all of them really important (for larger Nim audience, not just for your workflow)? How can we review PRs in time if you're constantly flooding us with new stuff? Long story short: new flags or constant pings don't help with faster reviews. Less "privatization" of Nim repo will.
Re: Revisiting my oldest Nim project.
> Bummer, I still like them better than json. :-) String stream only started to work with JS recently and still can't do pointer stuff. I wish binary formats was better supported in JS. > There are cases where you want to store a (timestamp, timezone) tuple Exactly, I view timestamp as kind of a string and timezone kind of language code. If you need to store what language a string is in, yes store it. But most of the time that is not needed, and you just need to display time in the user's "language." > nimble removes the src directory I never had an issue with that. Maybe you need to use staticRead instead of readFile? > float64 for timestamp I still will stand for float64 timestamp for my application. Yes there are special places like banking that don't use float points. They are special. You would not use float points for money too. For almost every one else float64 since 1970 fits the bill. * Seconds is the SI time unit. Not using it is like using decameters or distance. Its just strange. * Seconds from 1970 works great as its when unix time started. * You can't use int64 in JS. Most of my work is in JS. You can't encode that in json. So you would have to use two numbers ... maybe seconds and microseconds? BigInt in json looks like a pain. * I interface with many systems and they give me random scaling. I always have bugs with this conversions. Even with nim, is sleep() in seconds, milliseconds, or microseconds? In python I always know its seconds. Because everything else is seconds. Python does it best. Just use single scaling, its not so hard! Here is what I deal with on daily bases > * python 1.0 > * java 1000 > * js 1000 > * bigquery 1000_000 > * go 1000_000_000 > That is why I use float64 seconds from 1970 utc. > leap seconds I should add a j2000 mode as that will enhance my [https://github.com/treeform/orbits](https://github.com/treeform/orbits) library.
Re: oids library import + Karax --> error
Here is an explanation: karun tool compiles your code to javascript target with `nim js`. Read the manual to find out more. oids.nim uses c imports and wasn't build with the js target in mind. Thus it can't be compiled in javascript and errors. I hope that helped.
Iterator arguments
I'm trying how far I can get mimicking Lua's asymmetric coroutines in Nim, using iterators and some macros - not unlike asyncmacro. The manual is a bit vague about iterator arguments - it states that you need to provide the arguments to each call, or wrap the thing in a closure which does that for you. But I want to leverage the fact that I can pass _different_ arguments to each call - is that considered safe and well defined behaviour? It works for me now, but is this intented an something one can rely on to be like this in the future?
Re: proposal: PTAL tag to make it clear that a PR is ready again for review
Please no. If you want someone to have a look at your PR then bump the PR so it gets put at the top of our notifications or just ping the best person to review that PR (if you know who they are). All these title/tag changes are just noise and we've got enough of that already.
Re: Idea: Nim Online Conference
I think the consensus so far is that we will let the participants choose whether they wish to pre-record their talk or to do it live. I would personally suggest pre-recording it to give us the ability to stream the highest quality talk possible, but I understand that some dislike that approach so the choice will likely be there.
Re: oids library import + Karax --> error
Hmm I'm not entirely sure what you mean. I can understand that I can write pure Nim version of the mongo oid algorithm using the times and random standard libs, but I have no idea about really porting anything from Nim to javascript atm. Maybe I should read the language documentation regarding the javascript parts better... I just glanced the mongo objectid definition, is the bigendian32 purpose to swap the byteorder for th e time and random parts of the oid? Nevertheless thank you for your answer!
Re: oids library import + Karax --> error
It's hard to tell whether you're sarcastic in your answer and I'm not entirely sure was the question idiotic or something for which I could've found the answer via googling. (I did this and also glanced the Nim tutorials through without success tho) I just started learning Nim and coming from the dynamic Python isn't helping much ;) Regardless of everything thank you for your concise answer.
Re: Experimenting with a FreeRTOS OS Port
I've made a bit more progress. I've got an example esp32 Ethernet server to compile. But ran into something that's not quite clear: proc newSelectEvent*(): SelectEvent = var fds: array[2, cint] if posix.pipe(fds) != 0: raiseIOSelectorsError(osLastError()) ... Run There are no pipe's on FreeRTOS/ESP32 so I excluded them. It seems this just provides custom user event's and doesn't seem necessary.
Re: Revisiting my oldest Nim project.
agree with most points in top post except: * float64 for timestamp for the same reason as ppl don't use floating points for banking applications, but instead use either integer in some units eg cents or fraction of cents, or other fixed point arithmetics. floats will cause issues with rounding or difference wrt roundtrips, not to mention stringification I'd instead use: distinct int64 representing unix timestamp in either milliseconds (range of +/\- 300M years) or microseconds (range of +/\- 300K years); this will need BigInt for js platform. Caveat: leap seconds. note: if your application requires large range/precision, then use: distinct int128 (doesn't exist yet apart from compiler/int128.nim) or type Timestamp = array[2, int64]; this could be exposed in nim and work with both js, c, vm backends (but raises some concern regarding whether we'll then need compiler/int256.nim; hopefully something smarter can be used as that'd be wasteful) > I did not want to use json. I wanted to use binary formats .. compressed > binary formats. that's very application dependent; if you need fwd/backward compatibility, or a schema, or performance, json is bad, protocol buffer or capnproto would be better > Write good tools with command line parameters ideally, "everything is a library", but yes, sometimes a binary that wraps it is good > Always put your code into a src dir. I agree. src is just good hygiene that prevents bugs (eg prevents import pkg/cligen/oops_not_intended_as_source) and should be the default, if not enforced. > In my experience that's the best way to break your project because on install > nimble removes the src directory and then all your paths are wrong. [..]This > is so broken that even in nimble you had workaround like this The issue you mention is real, and the workaround is bad; IMO the fix is to improve nimble, or, if it can't be fixed, add an import syntax import this/nimblepkg/common
proposal: PTAL tag to make it clear that a PR is ready again for review
Currently, looking at [https://github.com/nim-lang/Nim/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc](https://github.com/nim-lang/Nim/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc) it's not clear which PR's are ready for review vs still being worked on: * using draft vs not draft is not good for that: github recently allowed marking a non-draft PR as draft, but that feature is unavailable if you're not a project member; also a PR that merely needs to address comments shouldn't really be considered a draft anyways (it works but just needs to address comments) * using CI passing vs failing is not good either because of flaky tests, and because a PR could have pending unaddressed comments and still be green # proposal * add a new "PTAL" github tag, with the meaning: either PR is ready for review for the 1st time, or, after a round of review and after all comments were addressed, it's ready again for another round; and all failures are (to PR author's knownledge) unrelated to the PR * users who don't have permissions to add a tag to their own PR can add [PTAL] to their PR title the feature would be optional to use, but PR authors who want to use it can, to increase visibility of their PR (once they've addressed all comments) without having to ping reviewers it makes those PR's easy to search for and we can easily filter by those in github search UI # note PTAL simply means "Please Take Another Look", this practice is common both in tech companies as well as in open source, eg: * [https://su2code.github.io/docs/Code-Review](https://su2code.github.io/docs/Code-Review)/ * [https://medium.engineering/code-reviews-at-medium-bed2c0dce13a](https://medium.engineering/code-reviews-at-medium-bed2c0dce13a) and unfortunately github doesn't have this feature builtin, so a tag is the best workaround
Re: rerunning CI works for github actions, sr.ht, but not azure pipelines
seems like you need special permissions to rerun from within azure pipelines UI (eg [https://dev.azure.com/nim-lang/Nim/_build/results?buildId=5365&view=results)](https://dev.azure.com/nim-lang/Nim/_build/results?buildId=5365&view=results\)), which I don't have, since it's possible for a PR against my nim fork but not a PR against nim repo. However I found another way that works just as well: doing it from github UI works perfectly; this is explained in [https://github.com/timotheecour/Nim/issues/211](https://github.com/timotheecour/Nim/issues/211) It should probably be mentioned in docs as I'm sure a lot of ppl are not aware of this and they restart the whole CI (eg via a push or via a close/reopen PR)
