The word "also called aliasing" should be removed, or people will get confused
with C++ reference.
I've got what feels like a minimal but useable widget API around Fidget. While
Fidget is fantastic for one off UI's it didn't really support pre-made widgets.
So I added it. :)
There's support for both stateful and non-stateful widgets.
Stateful widgets are divided into either `appWidget`s or `
I asked about implicitDeref [a while back](https://forum.nim-lang.org/t/6500).
The verdict was: it seems like a nice feature but it doesn't jive well with
others in its current form. For example a `var` parameter is supposed to never
be `nil` but with implicitDeref it could be!
And yeah, `ref s
It's mentioned in the [Roadmap for
Nim](https://github.com/nim-lang/RFCs/issues/437) issue on the RFCs repo under
"cleanup of experimental features". The problem is that even though this
feature may be useful, there's no guarantee the maintenance cost that comes
with it is worth it.
In the cas
Thanks for the quick reply and the code example, although it does something
rather different.
The [Nim
Manual](https://nim-lang.org/docs/manual.html#types-reference-and-pointer-types)
reads
_References (similar to pointers in other programming languages) are a way to
introduce many-to-one rel
So translate it to idiomatic Nim.
var a = newSeq[int]()
a.add [1,2,3]
var b = move a
b.add(4)
echo b # @[1, 2, 3, 4]
Run
Aliasing is very hard to reason about anyway, or in Python-ese "aliasing is
implicit behavior and explicit is better than implicit".
Translating this Python code
a = [1, 2, 3]
b = a
b.append(4)
print(a) # [1, 2, 3, 4]
Run
to Nim requires quite some manual dereferencing:
var a = new seq[int]
a[].add [1,2,3]
var b = a
b[].add(4)
echo a[] # @[1, 2, 3, 4]
@cblacke My point was that among "uni-typed" systems there can still be a big
difference between structured and unstructured data. "everything is a stream of
bytes" is as unstructured as it can get so naturally quoting rules become
important.
Thanks, this is much appreciated. I am starting to get it now
What Araq says is very fair in practice, but maybe requires clarification in
theory. Quoting rule complexity is not intrinsic to the command language
problem (which might almost be defined as "everything is a string literal but
without quotes unless they are 'necessary', whatever that means"). A
To make that a lot easier it would be nice if you could share your pre and post
versions. It could also be that your previous devel had a performance
regression in it
I use "normal" Vim with zah/nim.vim for syntax highlighting and nimlsp with
prabirshrestha/vim-lsp for deeper Nim integration.
I've been using devel for years. If I have some time I'll post a real
comparison. Maybe I'm just fooling myself.
wxnim works well for what I've used it for. But yeah the Gtk wrappers are good
as well.
> perfectly tailored educational content [...], culminating in "programming by
> StackOverflow copy-paste"
I think you're making a big leap here, I don't think these two facts are
related really.
> Specifically, the Gutenberg Bible revolutionized literacy in Medieval Europe.
I knew that compar
It is worth investigating in case it happened as an accident.
Please, [file a bug
report](https://github.com/indiscipline/tetronimia/issues/new) then. Don't
forget to mention your OS, your terminal and make a screenshot, if possible.
Does just clearing your terminal (usually, `Ctrl+L`) not help in your case?
> This is roughly how "Unix shells" and other command languages like Tcl and
> command.com work. Any "unitype-driven" system has all the same issues as an
> "everything is a PyObject" system, for all the same reasons.
There is actually a big difference between Unix shells and the PyObject system
18 matches
Mail list logo
