I think the answer is yes. The base type of UINT is int32 in winim. And the
prototype of GdipGetImageWidth is:
proc GdipGetImageWidth*(image: ptr GpImage, width: ptr UINT): GpStatus
Run
So following code should be work, too.
var width1: int32
if GdipG
With overloadable enums specifically, packages breaking the way they did was
expected. I [made an issue](https://github.com/nim-lang/Nim/issues/20077)
detailing the exact difference with no overloadable enums that breaks packages,
then I [made an RFC](https://github.com/nim-lang/RFCs/issues/468)
I'll give a recent exemple, [this
PR](https://github.com/nim-lang/Nim/pull/20298) broke libp2p (and other repos),
we noticed it fast since we have daily CI running against unstable
It was supposed to _improve_ enum resolution, but evidently made it worst since
it broke existing code. Now that i
> That said, I also agree that it's important for libraries themselves to add
> devel Nim to their CI (which is quite easy), because the main Nim CI doesn't
> run on infinite servers, and with each library the CI time is slowing down.
we do, but the problem here is that it takes up a lot of time
I make no claim to this being the ultimate best solution, but the direction of
this thread seems more concrete than my earlier vague comments. A simple seq
will actually do with some wasted space (probably a favorable space-time
trade-off.) So, presented purely for your consideration/to make tho
Ha ha, good point, you got me :)
Well, if developers are consciously sacrificing anything to _reduce cost of
development_ and casually mentioning their personal stdlibs when answering
forum posts then we're really doomed. :D
> I think this is neither clearer nor nicer than `let keys =
> toSeq(myTable.keys)`
That's an old story about [red/blue
functions](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/)
and it's already being discussed here.
> At the very least it wastes memory and allocat
I now think I was exaggerating, but I can't edit the post to delete it because
it's more than 2 hours old. Sorry for derailing
I think this is neither clearer nor nicer than `let keys = toSeq(myTable.keys);
let smpl = myTable[sample(keys)]`. At the very least it wastes memory and
allocations (seq->seq->seq) in the process. Instead of bunch of helper procs
which may never be reused I'd focus on solving the issue as it's
Something to mention regarding hindrances to development: This is a bit
unrelated and may be derailing, and I truly mean no disrespect to anyone, but I
have to say this at least once.
The entire first paragraph in your post is one sentence. There are no periods.
English like this is extremely h
You can do it like this, nice and clean.
Nim
let keys = mytable.keys
let sample = mytable.values.shuffle.take(10)
Run
With some helpers.
Nim
proc keys*[K, V](table: Table[K, V] | ref Table[K, V]): seq[K] =
for k in table.keys: result.ad
it matches the whole value, so should be something like "^.*dd.*$"
Probably best to check important packages only before a release, and not on
devel branches or continuous integration.
> like when a symbol is deprecated or removed
Just don't? ie actively spending time on breaking packages seems like a
counterproductive thing to be doing, and we've had this discussion in many PR:s
- it does a disservice to the Nim community because fewer working packages are
available for user
15 matches
Mail list logo
