<notsgnik>
i'm new to all this, i found the solution
<notsgnik>
_____
<notsgnik>
btw, in the future, do you think that the "if (element) in (iterable.obj) then ... end" will be implemented ?
<notsgnik>
______
Praetonus has joined #ponylang
<SeanTAllen>
what does "if (element) in (iterable.obj) then ... end" do notsgnik ?
user10032 has joined #ponylang
user10032 has quit [Remote host closed the connection]
user10032 has joined #ponylang
user10032 has quit [Remote host closed the connection]
notsgnik has quit [Ping timeout: 240 seconds]
user10032 has joined #ponylang
derka has joined #ponylang
user10032 has quit [Quit: Leaving]
derka has quit [Ping timeout: 248 seconds]
derka has joined #ponylang
user10032 has joined #ponylang
notsgnik has joined #ponylang
<notsgnik>
SeanTAllen, it iterate over the object and check if it is equal to the current object element
endformationage has joined #ponylang
atk is now known as t-
t- is now known as oop
derka has quit [Ping timeout: 240 seconds]
trevorriles has joined #ponylang
notsgnik has quit [Ping timeout: 264 seconds]
derka has joined #ponylang
derka has quit [Quit: derka]
<SeanTAllen>
no one has proposed that notsgnik
dsm__ has joined #ponylang
<dsm__>
i’ve compiled helloworld example with ponyc compiler. why ‘strip helloworld’ command removes behavior of main function?
<dsm__>
I’ve also tried other examples such as example/files, but it’s same with helloworld. it does nothing after i stripped the binary.
samuell has joined #ponylang
<SeanTAllen>
I've never used strip on binaries created by LLVM dsm__. Sounds like you shouldn't.
<dsm__>
I believed strip command should not alter the behavior of binary, am I wrong?
<SeanTAllen>
ive never in my life used strip so i cant answer that however, i believe you have empirical evidence that it does alter the behavior.
<SeanTAllen>
i'm not sure how strip would remove content from a binary and be able to guarantee the same behavior as before.
<SeanTAllen>
unless you compile with --debug, there's no debug info in a pony binary so i'm not sure what strip would remove
<dsm__>
should i understand it as current implementation of ponylang does output a strip-forbidden binary?
trusion has joined #ponylang
trevorriles has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<SeanTAllen>
pony uses your standard system linker. i don't think there is anything pony specific about it.
<Praetonus>
Optimised Pony binaries are already stripped of symbols
<Praetonus>
But something is unclear to me, are you saying that the runtime behaviour of your program changed after you used strip on it?
<dsm__>
Praetonus: yes.
<dsm__>
it prints nothing after i strip on helloworld example.
martinium has joined #ponylang
derka has joined #ponylang
derka has quit [Client Quit]
CcxWrk_ has joined #ponylang
samuell has quit [Quit: Leaving]
<trusion>
Hey everybody. I've just started using Pony, and I have a piece of what I need working mostly how I wanted. However I don't fully understand HOW it's working.
<trusion>
I'm trying to make Maps of heterogeneous (but loosely related) types, where the keys are effectively the types themselves. I.e. there can only be one instance of FooType in any Map, and all Maps will associate their (optional) FooType instance to the same key.
<trusion>
I'm trying to make Maps of heterogeneous (but loosely related) types, where the keys are effectively the types themselves. I.e. there can only be one instance of FooType in any Map, and all Maps will associate their (optional) FooType instance to the same key.
<trusion>
*sorry bad copy paste... I'm trying to make Maps of heterogeneous (but loosely related) types, where the keys are effectively the types themselves. I.e. there can only be one instance of FooType in any Map, and all Maps will associate their (optional) FooType instance to the same key.
<trusion>
I would expect either every call to get_type_id to be different, or every call to be the same, regardless of the type. Can anybody explain why the behavior is what it is, and if there's a better way to make this kind of heterogeneous container? Any help would be appreciated.
<SeanTAllen>
What's the problem trusion?
<SeanTAllen>
what do you think get_type_id returns?
<SeanTAllen>
I'm not sure what part exactly is surprising.
<SeanTAllen>
I'm not sure how that is related to get_type_id
<trusion>
That example shows that digestof can be different for different calls to the same function (since it's a different object), but that when it's a "in fun" primitive, it's always the same.
<trusion>
So what I don't understand, is why in the original example, the result changes based on what the type of the object is, since they all call what I would have assumed was the same function.
<SeanTAllen>
the original example being where you were doing get_type_id?
<SeanTAllen>
are you asking why get_type_id and digestof are different?
<SeanTAllen>
or did you switch questions?
acarrico has quit [*.net *.split]
CcxWrk has quit [*.net *.split]
cquinn has quit [*.net *.split]
darach has quit [*.net *.split]
catern has quit [*.net *.split]
j14159 has quit [*.net *.split]
catern_ is now known as catern
<trusion>
no. The original example refers to the get_type_id one. The other example was just demonstrating that there seems to be a rule that a given fun will generate the same anonymous primitive every time.
dsm__ has left #ponylang [#ponylang]
<trusion>
But then that rule seems to be violated with the get_type_id example, since it doesn't return the same value for different objects.
<SeanTAllen>
sorry, i'm totally lost. i'm not seeing the connection between get_type_id and digestof that you seem to be drawing.
<SeanTAllen>
you're making a leap that i'm not following.
<SeanTAllen>
get_type_id returns a unique indentifier for the given type.
<SeanTAllen>
it has nothing to do with the object, purely its type
<trusion>
Well the second example shows that's not the case. The different calls to PrimFoo's apply return different values, even though they're all just different instances of the same type.
<SeanTAllen>
digestof is on an instance
<SeanTAllen>
not a type
<SeanTAllen>
get_type_id is for the type
<SeanTAllen>
digestof is for instances
<SeanTAllen>
they are not the same thing
<SeanTAllen>
you are getting different values per instance because that is what digestof does
<trusion>
Well get_type_id is just defined in terms of the digestof of a local variable in the Animal trait. I don't see how it's any different than PrimFoo.
<SeanTAllen>
o sorry i missed what you were doing
<SeanTAllen>
`object end` is an object literal
<SeanTAllen>
its the same instance
<SeanTAllen>
over and over again
<SeanTAllen>
per type
<SeanTAllen>
i hadnt looked at what you were doing there, i assumed you had figured out how to expose pony's type id for classes and hadn't looked at the implementation
<SeanTAllen>
sorry
<SeanTAllen>
you want to get a unique identifier for a class?
<trusion>
No problem. I guess I'm asking why the object literal is different per type? How does it know to generate a different one when called on a Cat vs a Dog?
derka has joined #ponylang
<trusion>
But yes, my ultimate goal is to get a unique class identifier.
<SeanTAllen>
Praetonus: can answer better than I, I'm much more of a "runtime" rather than compiler person. My assumption would be that when your code gets compiled, that empty object literal you are creating is getting inlined on a per class basis.
<SeanTAllen>
The unique class id, should it be the same across differently compiled applications or just unique within your given application?
<SeanTAllen>
I assume the latter
<trusion>
Right. It just needs to be consistent for the entire duration the program is running on a given machine.
<SeanTAllen>
Pony generates that, its used in serialisation but I don't think its exposed. I'm looking though.
<trusion>
That would be great. Especially if it's something that could be called using just the class itself, instead of an instance of the class.
<SeanTAllen>
I don't see it exposed anywhere. Praetonus or jemc might know better than I.
<SeanTAllen>
I've never considered doing a hash where you want 1 entry per type, so there might be some other means of doing it but I'm not sure what it would be that is universal.
<SeanTAllen>
For your own code, you could add your own "identity" to each class and use that
<SeanTAllen>
Map allows you to define how you do identity (the "default" being the MapIs class)
<Praetonus>
trusion: The problem in your code is that `digestof` computes its result from the address of the object
<Praetonus>
Since you're creating a new object in every call, the address is always changing
<Praetonus>
In general digestof shouldn't be used to generate unique identities
notsgnik has joined #ponylang
<trusion>
Praetonus: Would digestof instances of a named primitive be consistent? The behavior that seems weird to be is the fact that the same object literal is generated for every Dog, and a different one for every Cat, and so on. I do understand why PrimFoo is different every time, it's why PrimPrim and get_type_id aren't always different that confuses me.
<SeanTAllen>
digestof is based on memory address trusion.
<Praetonus>
Ah, I see what you mean. I missed that in the code. So the reason is that object literals without any fields will be sugared to a Primitive, and since primitives have only one instance and the result of digestof is based on the address of the instance, you get the same result on every call
<Praetonus>
But I'd advise against relying on that behaviour since it's more of a compiler optimisation in order to avoid allocations. I think we should be able to expose type IDs to the programmer to cover this kind of pattern. It'd be more reliable
<Praetonus>
I'll add that on my list of RFCs that I should write up
<SeanTAllen>
Praetonus: i would if that has security implications for serialization.
<SeanTAllen>
err *i wonder*
<Praetonus>
It would be a read only access so I don't think it would be problematic
<trusion>
A standard way to do this would be a big help if possible. Either way thanks for your time!