Re: classic "can not open sdl2" ...
This isn't true... the linker simply needs to know where to find the shared library. Depending on what compiler / linker you're using - the syntax for providing a path to linked libraries can vary. If you're using gcc for instance, you can set the LIBRARY_PATH env variable or by specifying paths using -L when calling gcc, like -L/usr/local/lib You can run gcc with the -v flag to see what LIBRARY_PATH is currently set to.
Re: Memory regions / gc:regions
Well this feature is underdeveloped and so the code contains lies/stuff not implemented. However, `Channel` works and can be used to move a region to a different thread. Alternatively you can have a region in a global, shared variable and access it with a Lock.
Re: Memory regions / gc:regions
Gotcha - thanks for the explanation. I will play around with them today.
Re: Should we get rid of style insensitivity?
@runvnc "It's almost like there is an IQ test built into the language." This has nothing to do with IQ, this is not fullblown monads or something, it's a thing that people expect to be very simple and obvious and it isn't. (they might be wrong, but don't make wrong conclusions)
iup.getFile fails
import iup discard iup.open(nil,nil) var cs : cstring = "*.txt" echo iup.getFile(cs) iup.close() Run Program crashes before show the getFile result: SIGSEGV: Illegal storage access. (Attempt to read from nil?) Success if press the cancel button in file dialog. (Windows 7, iup30.dll)
Need help for a generic object field
Sorry for that basic topic but I want an object field to be able to handle two differents types with a clean syntax on the user side. No problem if the code behinds the scene is a hacky template or something, but the user should never need to see that. I written a simplified example. type Rect = ref object width:float height:float ConvexP = ref object vertices:seq[float] type Drawing = ref object shape:Shape # I want this to hold a Rect or a ConvexP # two stupid functions who just show if the program works. proc presents(rect:Rect) = echo "This is a rectangle " proc presents(convP:ConvexP) = echo "This is a convex polygon " var rect = Rect(width: 2.0, height:2.0) var drawing = Drawing() drawing.shape = rect drawing.presents shape # must runs the first version of "display" Run This code is wrong because Shape is still not defined. I want to avoid generics parameters because the code will be cluttered by many "[]", "Drawing" may handle several generic fields in the future, not only the shape. What is your suggestion ?
Re: Need help for a generic object field
Are you sure ? A colon ? Not an equal sign(=) ?
Re: Need help for a generic object field
I also want to know the answer. I have tried a lot. But strict typing is killing us. Now, i can compile this code only if i use 2 distinct members in Drawing.
Re: Need help for a generic object field
` type RectOrConvex: Rect | Convex ` Run
Re: Need help for a generic object field
Sounds like you want [dynamic dispatch](https://nim-lang.org/docs/manual.html#multiminusmethods). Note that `Rect | Convex` is not a concrete type, so you can't have `seq[Rect | Convex]`.
Re: Need help for a generic object field
> What is your suggestion ? When you already use ref object, you may consider inheritance. Or you may use sum types (union types) -- maybe bad if memory footprint of your objects differs a lot.
Re: Should we get rid of style insensitivity?
I guess a language- and compiler recommended style guide that a lot of people follow increases the value of the eco-system as a whole - just like a single developer is likely to output similar code and benefit from the familiarity that this brings, a whole community come together and do so, decreasing needless friction between libraries and making it more pleasant to use code from multiple sources. Thus, a system that's good for the community is one that guides the novice towards a safe and globally beneficial defaults, while it allows the master the freedom to step outside those bounds so as not to become a constraint. Seen through this lens, the case insensitivity feature does not really have to be removed - it simply can be hidden behind an option that allows you to turn it on when appropriate.
Re: Need help for a generic object field
> I want an object field to be able to handle two differents types with a clean > syntax on the user side Take a look at [Object variants](https://nim-lang.org/docs/manual.html#types-object-variants) section in the manual, maybe that is something you can use in your case.
Re: Need help for a generic object field
> But strict typing is killing us
I'll repeat what I have already tried to tell you several times, based on the
examples/questions you have posted previously.
I don't think 'strict typing' is what is killing you. It is your idea to do
things "the old way", like you did them in some other language, and when that
plan fails, you ask as how to patch it to make it work. Instead of doing things
the other, easier, way where you might not even need those patches.
I've already gave you link to Wikipedia'a entry for 'XY problem' so this time
I'll directly copy–paste it here:
> The XY problem is a communication problem encountered in help desk and
> similar situations in which the real issue ("X") of the person asking for
> help is obscured, because instead of asking directly about issue X, they ask
> how to solve a secondary issue ("Y") which they believe will allow them to
> resolve issue X. However, resolving issue Y often does not resolve issue X,
> or is a poor way to resolve it, and the obscuring of the real issue and the
> introduction of the potentially strange secondary issue can lead to the
> person trying to help having unnecessary difficulties in communication and
> offering poor solutions.
* * *
I'm sorry if this sounds rude — that is not my intention. My intention is to
help you so in the future you'll ask more questions about "X issue".
Re: Need help for a generic object field
Here you go:
type
Shape = ref object of RootObj
Rect = ref object of Shape
width:float
height:float
ConvexP = ref object of Shape
vertices:seq[float]
type Drawing = object # Don't use ref object if there is no need, this
involves the GC and is inefficient
shape: Shape
method display_type_of(self: Shape) {.base.} =
raise newException(ValueError, "Please implement display_type_of for your
custom shape")
method display_type_of(self:Rect) =
echo "This is a rectangle "
method display_type_of(self:ConvexP) =
echo "This is a convex polygon "
let rect = Rect(width: 2.0, height:2.0)
var drawing = Drawing()
drawing.shape = rect
display_type_of drawing.shape # This is a rectangle
Run
Re: Need help for a generic object field
I just read your answers carefully and I will tests these solutions, my project is much more complex than the example. Thank you all for taking the time to write such insightful answers.
Re: Should we get rid of style insensitivity?
Well said, @arnetheduck. Honestly, for the true master, you could do some pluggable system that allowed macro/compile-time proc-driven identifier transformation with the current rules as a simple activation maybe as a pragma on `import`. Then people could override that current "compromise" batch of ident rules with something even more idiosyncratic (e.g., that handled ALL_CAPS or maybe CAPPREFIX_Foo identifiers differently, as needed/wanted). You might need to declare a convention inside defining modules, too, though, if you depart from the default. Anyway, instead of quashing admittedly often time-waste-y arguments about (just some dimensions) of style with a totally unique set of ident rules (more than just "case insensitive" as @dom96 points out), give devs tools to manage disagreements.
Re: Need help for a generic object field
You seem to be attacking my each words carefully. But I do not want to take this as an attack. I would like to take this as a help as you said. I think there is no XY Problem in this case. Because you understood my real problem properly from my words. Well, You are right. My previous experience with other languages are causing some problem. But i am learning slowly.
Re: Need help for a generic object field
The inheritance way seems to be more easy for me. The case statement in that type declaration looks like Chinese for me (just joking :)) Well, you showed 2 methods and stated the pros and cons of those 2 methods. Thats really helpful. Now one can easily choose what they want from this. Great. Let me ask one question. In that code snippet you said to avoid using "ref" whenever not needed. What i understood is that using "ref" causes using heap memory. And you also said that it will affect the performance in a tight loop. Ok then, here is my question ; When we create GUI controls, is it safe to use "ref" rather than a normal object ?
Re: Should we get rid of style insensitivity?
Sorry if I didn't give enough context... I think its mostly they had a knee jerk reaction and didn't choose to understand it completely. Definitely not that they tried to compile something and found it problematic. I was giving an hour long talk at my workplace to our engineering department (mixed bag of C++, Go, Python, JS developers) about using nim's language features and potential uses. I did bring up the style insensitivity at one point, and just saw the reaction from different individuals. Also just having conversations with people, I've found that can sometimes turn people off from exploring more. If they're really interested, I think they might come around (or agree that its not such a big deal). To some developers, I pointed them to the wiki page on it, but I think they just inherently found it confusing. And the fact that it does require an explanation (albeit short) does speak that it add _[some](https://forum.nim-lang.org/postActivity.xml#some) complexity. Re @alehander42 's point - > it's a thing that people expect to be very simple and obvious and it isn't To be clear, I personally think it's a neat feature :) re: @GULPF I didnt know about --styleCheck - Thanks!
Re: Need help for a generic object field
If you want your program to spawn objects during runtime you'll need ref objects.
Re: Need help for a generic object field
> If you want your program to spawn objects during runtime you'll need ref > objects. Not really. For example, when you have a single value object and add() it to a seq, it is copied -- similar as C++ vector does copy when you use std::vector::push_back(). You can modify your value object then, and add next copy. Similar for other data structures like hash or tree. Of course seq uses a internal buffer allocated dynamically on heap, but we may not really notice that. kcvinu, of course you can use ref objects and inheritance for GUI stuff and much more. Ref objects are less efficient due to indirection of course, you have the ref on the stack, which points to the data on the heap, which is most often not in cache. That may make a difference of a few 100 clock cycles, which is less than 100 ns. May be much for high performance computing and games, not that much for us ordinary people.
Re: The future of NIM's WASM?
This thread could use some pointless grumpy whining. (Or at least that's all I can contribute right now.) I'm wondering about the future of `nim js`. Nim has invested considerable effort into the JS backend - time that could have been invested into delivering a more competitive "product" with just the C backend, stabilization, documentation, etc. Then WASM comes along and (although it's not fully baked _yet_ ) it seems that Nim's JS backend efforts are now somewhat less valuable... And remember - you are mortal! _Be depressed... Be very very depressed..._ Fin.
Re: Need help for a generic object field
Yes "ref" and "new" aren't the only way to create memory dynamically. I written my post too quickly.
FE web libraries
The JS ecosystem is a mess - I'm sure many of us will agree regarding that sentiment. I'd like to gather thoughts about Nim's current FE web libraries and if we think we should expand upon them further... Most people, who have built a website in the past half-decade are familiar with react and angular. Not to lump all FE web libraries into one category - but these libraries tend to rely on an implementation of a Virtual DOM and then an algorithm to diff between the virtual DOM and the actual DOM. The reason this is done in the first place, is to help eliminate inconsistencies between app state and ui state. More recently, a few libraries have emerged - [https://github.com/WebReflection/hyperHTML](https://github.com/WebReflection/hyperHTML) and [https://github.com/Polymer/lit-html](https://github.com/Polymer/lit-html) These libraries are focused on the web component specs, which if you're not familiar with, are a different beast all together - [https://www.webcomponents.org/specs](https://www.webcomponents.org/specs) React and web components are not 1:1 - for instance, web components don't offer a solution to application state management or even local component state - in fact they don't define components, they define custom HTML elements. Still - you can build upon these specs to define your own custom elements, and then add glue to a state management library like redux or mobx or what have you... I guess the question being asked here is - Is Karax sufficient? Would it be better if it was extended to support template literals so that you could take advantage of some of the performance benefits purported by hyperHTML / lit-html? Does anyone care?
Re: FE web libraries
I recently came to Nim because of the amazing JS backend. My 2c: The JS backend is really powerful, but it needs a bit of modernization to continue to attract more people to the Nim ecosystem. I've been frustrated a time or two about lack of ES6 module support. It would be delightful to be able to use features like Web Components (and dozens of others) without having to write JS shims or Nim macros. Karax is really fun, and very inviting. The Nim Forum software is a solid example of a fully functional app in Karax. However, there doesn't seem to be a way to just clone it and run. There are incompatibilities with the latest Nim release and the forum code, the Nim version specified in the nimble config doesn't exist. IMHO the forum software should be kept up to date with the latest nim releases, because it's the largest codebase representative of how to do Nim on both frontend and backend. Finally, WASM should be prioritized as a target. So many possibilities for apps with Nim backend, nim/js frontend glue, and nim/wasm frontend. Nim should catch this wave while it's still cresting! Ramblings from a nim-n00b.
Program that using OpenMP crashes with segfault without -d:release flag
I tried to compile OpenMP [example](https://rosettacode.org/wiki/Concurrent_computing#Nim) from RosettaCode but it just fails with segfault. After playing with it a bit i found out that it compiles perfectly normal with -d:release flag, i.e.: $ nim --passC:-fopenmp --passL:-fopenmp c main 1>/dev/null 2>&1 && ./main Enjoy Segmentation fault Run With flag: $ nim -d:release --passC:-fopenmp --passL:-fopenmp c main 1>/dev/null 2>&1 && ./main Rosetta Code Enjoy Run Is this a bug or I am missing something?
