profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/zielmicha/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Michał Zieliński zielmicha Poland https://zielmicha.com I'm a developer with a passion for networking, cryptography and programming languages theory.

zielmicha/adb-wrapper 33

Run adb commands on many devices.

metacontainer/metac 28

MetaContainer - share access to your files/desktops/USB devices securely (version 2)

husarion/hFramework 23

hFramework is a library for creating real-time software for robotic & mechatronic devices

kju-lang/kju 3

KJU language compiler - an educational project

zielmicha/arduino-face-follow 2

When ran on Arduino with two servos and camera mounted, follows faces.

darianhickman/VillageMakeover 1

Village Makeover is a nonprofit fundraising platform. As you build your online village, the money you spend builds real villages. For example buy a well for your village and you donate to construction of a real well in Ndola Zambia. At present all donations are managed through Seeds of Hope International Partners (www.sohip.org).

zielmicha/ap-tools 1

Various tools for managing openwrt access points.

zielmicha/authserver 1

Simple LDAP server with Django-based frontend

fork dom96/freenode-exodus

Projects and channels that have decided to leave Freenode. (Leave count as of 2021-06-19: 902)

fork in 4 hours

issue commentnim-lang/RFCs

APIs should have typesafe self-documenting time units, eg `proc sleep(t: Duration)`, allowing `sleep(1.millisecond)` etc

I wonder if a std/units should exist too, for basic unit ops without converting twice to/from int/float, kinda 1.Hours + 55.Minutes or $(42.Microseconds) etc

https://github.com/SciNim/Unchained

I'm obviously a fan of this, but not sure if it should be a standard library feature to be honest.

timotheecour

comment created time in 7 hours

issue commentnim-lang/RFCs

Unicode support for infix operators

For Vim you don't need any plugins, it has this built-in.

:help digraphs
:help i_ctrl-k
whiterock

comment created time in 8 hours

issue commentnim-lang/RFCs

APIs should have typesafe self-documenting time units, eg `proc sleep(t: Duration)`, allowing `sleep(1.millisecond)` etc

I wonder if a std/units should exist too,

I've implemented std/units in a private branch, see https://github.com/timotheecour/Nim/issues/760 which allows user defined units as distinct float and automatically computes arbitrary powers from those in expressions, eg:

runnableExamples:
  type
    Length = "m".makeUnit # can be also defined from other powers of other units
    Time = "s".makeUnit
    Mass = "kg".makeUnit
  assert $(Time(1.2)/Length(3.2)*Mass(5.4)*Mass(5.4)) == "10.935's*1/m*kg²"

but that'd require a separate RFC and isn't needed for this RFC (in particular, durations should be integral, not FP, whereas units are more useful as FP in most applications)

for basic unit ops without converting twice to/from int/float,

what do you mean twice? the conversion should be 1-way and propagated throughout stdlib until the point where it's consumed by final OS call into the unit it needs; the goal would be to only consume Duration through and through.

The only problem I'm facing to implement this is that I'm not sure the implementation of Duration is the right one, as it uses this:

type Duration* = object
  seconds: int64
  nanosecond: range[0..999_999_999]

which doesn't lend itself for efficient operations.

So I'm instead considering introducing a different type to represent durations that doesn't incur performance penalty, eg:

# in system:
type int128* {.magic: Int128.}
  # in C backend, uses `__int128` if `#ifdef __SIZEOF_INT128__` is defined,
  #   else falls back to software emulation as implemented in compiler/int128.nim
  # in VM, uses compiler/int128.nim
  # in js, uses jsbigints or a wrapper around it if we care about preserving bounds checking
  type Int128* {.importc: "__int128", nodecl.}

# in std/durations:
type TimeUnit* = distinct int128

The name can be bikeshedded, eg: Nanoseconds, Timespan, Dur etc...

The alternative would be to use int64 but it can "only" represent ranges +- 292 years in nanoseconds, which can be a problem if doing math involving calendar year (eg 2021) + offset operations.

timotheecour

comment created time in 8 hours

issue commentnim-lang/RFCs

Unicode support for infix operators

@konsumlamm , @HugoGranstrom ,

There is at least 2 types of Latex-inspired input methods:

  • Various editor plugins for Vscode, Vim, Emacs and other editors. One can also install Julia plugin for all those editors, it works for non-Julia files also!
  • Use OS input methods
    • For Windows you can use https://github.com/clarkgrubb/latex-input#windows-install. I've just checked it, it works. It's claimed to work for Mac OS X also (i did not check)
    • For Linux there is ibus-table-latex already in repositories, it's always working for me: \otimes → ⊗. There is also similar fcitx-table-latex

Usually you just start typing sequence \ot and then press space or tab and the symbol is input!

whiterock

comment created time in 8 hours

issue openednim-lang/RFCs

Memoization stdlib

Memoization for functions should be in stdlib.

Basic Memoization is relevant in a function oriented lang like Nim.

Does not have to be the fastest in the world, an average memoization is still better than no memoization, can start with a Table-based implementation or similar, can be a macro too.

Should take few lines (~500 lines at most), including a runnableExample.

Memoization should work for JavaScript targets too.

Can provide good performance improvements for very few lines.

Why not implement your own ?

Yes, users can implement a custom one, but then each lib author will do their own, then in a project with multiple libs the implementations will not be compatible, that kinda defeats the whole purpose of memoization, 9 caches instead of 1.

How is it done in other langs ?

  • https://devdocs.io/python~3.9/library/functools#functools.lru_cache

created time in 9 hours

issue commentnim-lang/RFCs

APIs should have typesafe self-documenting time units, eg `proc sleep(t: Duration)`, allowing `sleep(1.millisecond)` etc

I wonder if a std/units should exist too, for basic unit ops without converting twice to/from int/float, kinda 1.Hours + 55.Minutes or $(42.Microseconds) etc

timotheecour

comment created time in 10 hours

issue commentnim-lang/RFCs

Unicode support for infix operators

Maybe this can become some kind of source code filter?

#? unicodeops
echo a ∧ (b ∨ c)
echo a ± b
echo a ⊗ b
var a, b, c: bool
echo `and`(a, `or`(b, c))
echo plusMinus(a, b)
echo kronecker(a, b)

Each operator would translate to a call to a name, so you don't have to define procs using the operators. I don't know if it's fine for the compiler to decide this operator-to-name table. It's also not really like the other source code filters in the changes it makes, so I don't know if it's the best fit.

a ⊗= b could also get translated to a = kronecker(a, b) instead of kroneckerAsgn(a, b), but I think it should just not be supported since it's not fully unicode. It could cause a lexer error on these operators, as well as ∧∨ and ∨+.

whiterock

comment created time in 11 hours

issue commentnim-lang/RFCs

std/prettyprints: pretty print any expression (including with cycles), customizable

It exists as a package already; https://github.com/treeform/print, I don't think absorbing/obsoleting packages into the stdlib is healthy for the ecosystem at whole. We should simply ship a bunch of packages with the installation to give them exposure and use.

treeform/print could be a great addition to fusion?

timotheecour

comment created time in 14 hours

issue commentnim-lang/RFCs

Unicode support for infix operators

a ∧ (b ∨ c) won't ever make it into Nim's stdlib/core for the simple reason that and / or are more readable and very special: They are control flow, in a or b the b is not evaluated if a is true. This means they are not the common logical operators.

I personally don't care if it goes into stdlib, but with regards to the special treatment / short circuiting you mention: Why would something like this not do it?

template `∧` (a, b: untyped): untyped =
  a and b

thoughts about unicode editor support: one option that comes to mind and which should be easy is replicating what Julia does i.e. expanding e.g. \pm to ± on tab or automatically. ultisnips for nvim comes to mind, or hypersnips for vscode - should be straightforward and useful for the mathy crowd which already knows latex.

whiterock

comment created time in 15 hours

PublicEvent

issue commentnim-lang/RFCs

Unicode support for infix operators

I agree with @konsumlamm that there should be ascii alternatives offered by libraries for the base functions at least so that you could write code that performs the same tasks (although in slightly different ways) witg both the Unicode and ascii alternatives. For example the a ⊗= b is equivilent (although more efficient perhaps) to a = kronocker(a, b). So both kinds of users would be able to use the library.

A note on inputting unicode charcters on Windows. Several options like Windows + . and WinCompose hs been brought up that aren't too convoluted to use. Although I haven't checked whether they support all of the proposed symbols in the RFC.

whiterock

comment created time in 20 hours

release mwarning/trigger

v3.3.2

released time in a day

push eventhusarion/panther_lights

Krzysztof Wojciechowski

commit sha ad4b0787c6a08832c60b4c1f0f374cef9aaa5dd0

Add unit tests

view details

push time in a day

issue commentnim-lang/RFCs

Unicode support for infix operators

IMO it's the opposite. If you offer ⊗, only offer ⊗, aliases are frequently more confusing and don't scale well. "Is there a difference between ⊗ and kronecker?" Now that we have ⊗= we also need kroneckerAsgn...

I disagree. Many people (including myself) wouldn't want to use unicode operators, simply because it's not easy to type. You either need some keyboard layout that supports unicode operators, or copy-paste them from the docs every time you wanna use them. So as a result, they probably just wouldn't use libraries that only provide unicode operators (without ASCII alternatives), which could be avoided very easily.

whiterock

comment created time in 2 days

issue commentnim-lang/RFCs

Stronger local type inference

@beef331 This is true but completely unrelated to the enum situation. This RFC should be split up into different parts. This RFC should be called "Overloadable enum names"

beef331

comment created time in 2 days

issue commentnim-lang/RFCs

Deprecate 'unsafeAddr' and make 'addr' available for all addressable locations

No one ever said unsafeAddr was badly named in being exactly as safe as addr. Quantifying this is hard because it is NOT about examples of "how it works" as you seem above to think are somehow persuasive. Rather, you want software lifecycle examples where the complicating distinction prevented many programmers from making important mistakes instead of just reflexively changing addr to unsafeAddr, as @Araq explained in his opening comment. In short, since you aren't really even arguing from the same perspective, disagreement is unsurprising. The benefit was, again explicitly, language simplicity which it is true may be subjective not "tangible", but many/most benefits are!

It may clarify to discuss the opposite direction of this RFC which relates to this benefit. If unsafeAddr is helpful, ptrs remembering how they were created might be even more helpful, no? By default blocking writes to memory in some far removed part of the call stack from ptrs that came from unsafeAddr is "safer". This move opens up a whole "const correctness" can of worms {Nim gets a shout out in today's version! }. Do we go all the way, even past FFI boundaries for the C/C++ backends that have const pointers? How many programmers just cast away constness in const-correct languages? Should they? Maybe not. Would Nim programmers? This is the "same perspective playing field" upon which you should argue. It is admittedly quicksand.

Since it is very hard to assess all this objectively (or even systematically) people mostly argue by bald assertion. Here's one - it's already a very bad sign that long-time Nim users need to ask about the distinction. Maybe that happens because pointers are needed so rarely and keeping up that good work however/wherever & making it more rare rather than adding new ones is what matters in the end?

Araq

comment created time in 2 days

issue commentnim-lang/RFCs

Unicode support for infix operators

A couple of remarks:

a ∧ (b ∨ c) won't ever make it into Nim's stdlib/core for the simple reason that and / or are more readable and very special: They are control flow, in a or b the b is not evaluated if a is true. This means they are not the common logical operators.

Unicode based operators should be reserved for other math heavy packages and the stdlib should avoid them. At least for the first couple of years.

Libraries offering for example ⊗(x,y) but not kronecker(x,y). This should be discouraged

IMO it's the opposite. If you offer ⊗, only offer ⊗, aliases are frequently more confusing and don't scale well. "Is there a difference between ⊗ and kronecker?" Now that we have ⊗= we also need kroneckerAsgn...

whiterock

comment created time in 2 days

fork piotrantosz/Best-README-Template

An awesome README template to jumpstart your projects!

fork in 2 days

issue openednim-lang/RFCs

Unicode support for infix operators

Unicode support for infix operators

Abstract

Allow certain unicode characters to be used as infix operators akin to but more restricted than Julia allows it.

Motivation

Allows for beautiful linear algebra code, can be helpful in using code to show off algorithms in a Computer Science kind of setting, is a very much loved feature of Julia, etc. The initial idea for this came from https://forum.nim-lang.org/t/2968

Description

I propose to allow the following characters to be used as infix operators:

Parsed with the same precedence as +

± ⊕ ⊖ ⊞ ⊟ ∪ ∨ ⊔

Parsed with the same precedence as *

⋅ ∘ × ⊗ ⊘ ⊙ ⊛ ⊠ ⊡ ∩ ∧ ⊓ ∙ ⋆

which is a quite small subset taken from what Julia allows: cf. https://stackoverflow.com/a/60321302/4038300 Note: This RFC should not fail on the grounds of one character here. It's just my initial proposal, feel free argue why some characters should be additionally included or which ones to be omitted.

There should be no confusion about precedence here!

Potential downsides: Libraries offering for example ⊗(x,y) but not kronecker(x,y). This should be discouraged, as to not hinder people using a library just because they cannot easily type these unicode glyphs - it should always be optional, I guess we cannot enforce this but to put it in the docs / a style guide.

Examples

So for example consider the hadamard kronecker mixed-product property:

Before

doAssert hadamard(kronecker(A,B), kronecker(C,D)) == kronecker(hadamard(A,C), hadamard(B,D))

After

doAssert (A ⊗ B) ∘ (C ⊗ D) == (A ∘ C) ⊗ (B ∘ D)

Or for people that love the brevity of math notation for logic consider:

Before

let truth = a and (b or c)

After

let truth = a ∧ (b ∨ c)

Implementation

I am not a Nim contributor yet, but I imagine the implementation would be rather easy :)

Further thoughts?

This makes all code unreadable ??? No it does not. It is optional, we choose a subset of unicode characters that are distinguishable and whose precedence is obvious. Consider also in your argument against it that we have things like the %* macro already in json.nim

@Araq suggested adding additional unicode parentheses to Nim. It's probably wiser to make a separate RFC about that? In any case it is better, if he suggests which symbols he wants and his general thoughts on it, since its his idea! :)

I could imagine lots of cool mathy things to take life in the sugar.nim package or perhaps more wisely (?) a separate package, since sugar.nim also provides these pretty abbreviations for people that appreciate that.

created time in 2 days

push eventhusarion/panther_lights

Krzysztof Wojciechowski

commit sha 0d55582e4bbf37fefe945e1bf55ef7a554817af0

final ros service version

view details

push time in 2 days

issue commentnim-lang/RFCs

Stronger local type inference

Another place this could be useful is in expressions, take the following into consideration.

proc bar = discard

proc foo: proc() =
  result = proc() =
    discard

proc doSomething: proc() =
  case true:
  of true: bar
  of false: foo()

Presently this errors at of false: foo() due to it being a closure and bar not being one as the case statement is looking for proc(). Given the information that the expression needs to be a proc(){.closure.} the error would be moved to the correct line which is the of true: bar there is no converter or way for it to presently be turned into the correct return type.

beef331

comment created time in 2 days

issue commentnim-lang/RFCs

Deprecate 'unsafeAddr' and make 'addr' available for all addressable locations

I'm against this RFC, even if everyone else seems to think it's a good idea. addr is unsafe, in large part because it allows stack addresss escaping their stackframe. This is actually actually a solvable problem, which I solved in https://github.com/nim-lang/Nim/pull/14976 (see extensive tests).

But unsafeAddr is strictly less safe than addr, violating type safety guarantees in more severe ways (eg const-ness or even ROM).

example 1

nim r main

when true:
  let s = "abc".cstring
  # s[0].addr[] = 'x' # CT error
  s[0].unsafeAddr[] = 'x' # RT error: SIGBUS
  echo s

example 2

nim r -b:js main

when true:
  type Foo = object
    counter: int
  proc fn(a: Foo) =
    # let b = a.addr # CT error
    let b = a.unsafeAddr # RT error below in js: TypeError: Cannot read property 'counter' of undefined
    echo b[].counter
    echo a
  var f: Foo
  fn(f)

example 3

nim r main with addr, it'll give CT error with unsafeAddr, you'll get different values at CT vs RT: CT: prints 5 RT: prints 3

what worse, this depends on Foo.sizeof; eg with -d:case2a you'd get RT: prints 5 instead

when defined case2:
  type Foo = object
    counter: int
    when defined case2a:
      data: array[100, byte]
  proc fn(a: Foo) =
    # let b = a.addr # CT error
    let b = a.unsafeAddr
    b[].counter += 2
  proc main =
    var f = Foo(counter: 3)
    fn(f)
    echo f.counter
  static: main()
  main()

In practice, I think the distinction never found a bug, you use 'addr', the compiler complains, you use 'unsafeAddr' instead, "problem solved".

I just showed 3 simple examples above where addr would give CT error and unsafeAddr would give runtime errors or inconsistent results; each backend is affected, in different ways: c, js VM.

unsafeAddr is a useful escape hatch when you know what you're doing, but at least the compiler tells you you're in uncharted territory. If we started to conflate addr and unsafeAddr, you'd lose this distinction.

In summary, conflating addr and unsafeAddr doesn't fix any bugs or enable any new features, and it does make the langauge less safe.

Araq

comment created time in 2 days

PR opened KSIUJ/gutenberg

Bump postcss from 7.0.35 to 7.0.36

Bumps postcss from 7.0.35 to 7.0.36. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/postcss/postcss/releases">postcss's releases</a>.</em></p> <blockquote> <h2>7.0.36</h2> <ul> <li>Backport ReDoS vulnerabilities from PostCSS 8.</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/postcss/postcss/blob/main/CHANGELOG.md">postcss's changelog</a>.</em></p> <blockquote> <h2>7.0.36</h2> <ul> <li>Backport ReDoS vulnerabilities from PostCSS 8.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/postcss/postcss/commit/67e3d7b3402c5d3d036ab7c1e781f86910d6ca72"><code>67e3d7b</code></a> Release 7.0.36 version</li> <li><a href="https://github.com/postcss/postcss/commit/54cbf3c4847eb0fb1501b9d2337465439e849734"><code>54cbf3c</code></a> Backport ReDoS vulnerabilities from PostCSS 8</li> <li>See full diff in <a href="https://github.com/postcss/postcss/compare/7.0.35...7.0.36">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

pr created time in 3 days

create barnchKSIUJ/gutenberg

branch : dependabot/npm_and_yarn/postcss-7.0.36

created branch time in 3 days

push eventhusarion/docs_new

radeknh

commit sha 97fd8c0cad7cd758b36ad8073b78920f272a87f0

Updated on-board computer info

view details

push time in 3 days

issue openednim-lang/RFCs

replace `callsite` by `callTree`

proposal 1

  • add a type to represent a raw TLineInfo as used by the compiler (eg: NimLineInfo); unlike LineInfo it doesn't interpret the filename and just faithfully represents it; add macros.nimLineInfo API analog to macros.lineInfoObj to retrieve it from a NimNode

proposal 2

in macros, make proc error(msg: string; n: NimNode = nil) also accept NimLineInfo instead of just n; NimLineInfo can be used when the n is not available ditto with some other APIs eg warning

proposal 3

add proc callsiteNimLineInfo() which just retrieves the NimLineInfo instead of callsite which retrieves the full NimNode and requires copyTree

proposal 4 (independent of proposal 1, 2, 3)

add callTree which works exactly like the deprecated callsite except it requires the macro where it's called from to be annotated with a new pragma {.callTree.}, otherwise it gives an error

migrate existing calls to callsite to use the new callTree, and turn callsite into an error unless -d:nimLegacyCallsite is used; when -d:nimLegacyCallsite is not used, we can now avoid the expensive calls to copyTree in all places except ones that use {.callTree.}

note

callsite has its uses so outright removing it is not good, however the proposed callTree should address all concerns, in particular avoiding copyTree on each call except the few that are enabled via {.callTree.}

created time in 3 days

issue commentnim-lang/RFCs

Developer tooling

I just wanted to chime in and say that I've been really happy using the IntelliJ plugin that @piotrtomiak wrote, along with the CLion IDE. Indexing is fast, highlighting is flawless as best as I can tell, and completion/code navigation works well for simple cases. There's plenty that it can't handle currently, but it works often enough to be useful, and when it fails it's pretty graceful about it.

One major limitation is the lack of toolchain support. It seems to use the first Nim compiler that it finds on the path, and doesn't support building with nimble. However, CLion helps a lot here, as it makes it pretty easy to throw together a custom build using whatever commands you want, which can then be debugged from inside the IDE if built using --debugger:native. There's also a File Watcher plugin that I'm using to automatically run nimble c check ... on each change, which will properly highlight warning/errors, as well as creating clickable links to navigate directly to errors. It also automatically runs my tests whenever I change them, again with error highlighting and the ability to navigate directly to errors.

The whole thing was a bit of a pain to setup, but it's definitely my favorite nim development environment now that I mostly have the kinks worked out. At some point I'm going to try to release a project template that has the custom build and file watcher stuff pre-configured.

For folks who already use Jetbrains IDEs it's definitely worth a look. For everyone else it's probably a bit early, but it should be a 1st class experience soon enough if @piotrtomiak is able to keep working on it.

mratsim

comment created time in 4 days

issue commentnim-lang/RFCs

Developer tooling

Yeah, personally I'll just revert back to an old regexp based syntax highlighter and that's it. I'm fine with that and just using the Nim compiler from the command line. It has worked well enough for all those millions of C devs in the past 50+ years :)

I am getting used to it, but the big problem is for beginners it just highers the bar for entry significantly.

The LSP stuff is cool in theory, but if it's not 100% reliable, then it just gets in the way. Autocomplete would also be cool, but it's not a must. A beneficial side effect of NOT having it is that you'll remember a bit better where things are in your project exactly :)

When one browses the issues on nimlsp or nim.nvim they'll see that it eventually comes down to a hard to debug problem that most likely resides in nimsuggest. But yeah I found this spartan way of programming very insightful, but this RFC makes plenty of arguments why the current state is not desireable.

Tooling is hard though, I'm glad this RFC exists and that IC might mean more reliable tooling. Exciting times ahead!

mratsim

comment created time in 4 days