hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
<K-ballo>
people still do west-const?
<Yorlik>
Only newbies like me
<Yorlik>
In all my self taught C++ I never found any hint we should use east const ony
<Yorlik>
First time I learn about it today
<K-ballo>
west const does not fit the model, leads to false expectations.. but yeah, there's a lot of ancient material out there all using west const
<Yorlik>
However: testdata* ptr = td_array_base; Now behaves as I expected.
<Yorlik>
Good to have that cleared.
<Yorlik>
I'll be double cvareful now in const land
<Yorlik>
However - I totally believe it ewill make my code safer spamming const where appliable
<Yorlik>
Also change my prototype from T * allocate( size_t n = 1 ); to T * allocate( size_t const n = 1 ); n is never changed anyways
<Yorlik>
I believe all these little details will add up in the end.
<K-ballo>
that const means nothing in the "prototype"
<Yorlik>
Even pondering to make it a const T * allocate( size_t const n = 1 ); or would that protect the data and not the pointer?
<K-ballo>
the "prototype" is for the caller, that const is entirely irrelevant to the caller
<Yorlik>
true
<Yorlik>
only by ref would matter
<K-ballo>
nn.. you are still confused over top-level const versus inner const
<Yorlik>
How would I protect the value of the returned pointer (the address, not the data) here?
<K-ballo>
top-level const is irrelevant in "prototypes", you can freely add those in definitions as they only affect the body
<Yorlik>
I mean - const params are protected from change in the body, right?
<Yorlik>
Whoich deosn't really mater for by value params but for by ref params it does.
<Yorlik>
iirc
<K-ballo>
ref params can't have top-level const
<K-ballo>
you can't have T& const param
<Yorlik>
I think i need to do soem serious re reading of stuff.
<K-ballo>
always put const to the right, then it always applies to what's immediately on the left
<Yorlik>
So would T * const func(U const * const); be possible? a * parameter where I can neither change the pointer nor what it's pointing to and returning a pointer to mutable data but the pointer can't be changed?
<Yorlik>
woops - forgot an identifier for the param
<Yorlik>
Like: T * const func(U const * const p);
<Yorlik>
or rather: T * const func(U* const p const );?
<K-ballo>
it was right the first two times
<K-ballo>
const applies to types
<K-ballo>
I don't quite see the point of the return though, you can always freely copy from a const pointer
<K-ballo>
T * const ptr = ...; T * ptr2 = ptr;
<Yorlik>
And T const * P = ... would be immutable data of mutable pointer?
<K-ballo>
not quite immutable, just cannot be modified tru *P
<Yorlik>
Thats what I meant
<Yorlik>
That instance of access so to say
<Yorlik>
So - there are 12 ways to place const and * in an int const * const p declaration ... This is madness ...
<Yorlik>
Time to rewrite some tests and get rid of my crazy superfluous casts - thaks for all the clarifications everyone!
<K-ballo>
lol, there's.. two?
<K-ballo>
there's U and U const, with U = int, or U = int*, or U = int const*
<Yorlik>
Do don't really wanna see them, do you ?
<K-ballo>
even if I count each of the above combinations I still get just 6, not 12
<Yorlik>
const int * const a = 1;
<Yorlik>
int const * const a = 1;
<Yorlik>
const int * a const = 1;
<Yorlik>
int const * const a = 1;
<Yorlik>
/ add the variation for the * alignement:
<Yorlik>
const int *const a = 1;
<Yorlik>
int const *const a = 1;
<Yorlik>
const int *a const = 1;
<Yorlik>
int const *const a = 1;
<Yorlik>
const int* const a = 1;
<Yorlik>
int const* const a = 1;
<Yorlik>
const int* a const = 1;
<Yorlik>
int const* const a = 1;
<Yorlik>
:)
<K-ballo>
some of those don't even compile
<Yorlik>
Really? Which would that be?
<K-ballo>
and * alignment, whitespace
<Yorlik>
I didnÄ't test all of em
<K-ballo>
if you count whitespace you can have infinite variations
<Yorlik>
You can have T * a
<Yorlik>
naw - double ws would collapse
<Yorlik>
thats cheating
<K-ballo>
there really are just the two places, which are not even distinct, everything else are formatting combinations
<K-ballo>
U const and const U
<K-ballo>
and what gives those two different meaning is parsing, if U is a type alias then they are 100% equivalent
<Yorlik>
OK - 3 don't compile indeed
<Yorlik>
9 left
<K-ballo>
divide by 3 for whitespace, 3 left?
<K-ballo>
you have a repeated pattern, that accounts for the remaining extra one
<Yorlik>
Working on it - found another mistake - but its even more crazy
<K-ballo>
and then all you have left is `int const* const` and `const int* const`, which is the same type
<zao>
The rules around const is that it is always on the right of the thing it applies for, except in the innermost nesting, which is unfortunately the common place where legacy materials/projects put it :)
<Yorlik>
So - this compiles:
<Yorlik>
int const i = 1;
<Yorlik>
const int* const a1 = &i;
<Yorlik>
const int const* a3 = &i;
<Yorlik>
int const* const a2 = &i;
<Yorlik>
int const const* a4 = &i;
<Yorlik>
const int *const a5 = &i;
<Yorlik>
int const *const a6 = &i;
<Yorlik>
const int const *a7 = &i;
<Yorlik>
int const const *a8 = &i;
<Yorlik>
const int * const a9 = &i;
<Yorlik>
int const * const a10= &i;
<Yorlik>
const int const * a11= &i;
<Yorlik>
int const const * a12= &i;
<Yorlik>
The last is my favourite :D
<Yorlik>
Most horrible of em all methionkls
<Yorlik>
I tended to use west const because of reading like " a constant(adjective) T" but I will read like " a T constant(noun)" now.
<K-ballo>
helps to read left-to-right, when not dealing with C's spirals.. `int const* const p;` reads as "p is a const pointer to a const int"
<K-ballo>
sorry, that's right to left
<Yorlik>
I think the way how you translate stuff into natural language internally is really important and should be taught.
<Yorlik>
C spirals are up and clockwise, right?
<K-ballo>
I have no idea, and I don't intend for that to change.. there's no need to have them
<Yorlik>
Seems I had a little const explosion, but I guess it's all fixed now.
<Yorlik>
Thinking about it a const void* is actually a funny thing. If I undertsand correctly it translates to void const * which would be a pointer pointing to nothing that will never change ... :/
<K-ballo>
yes it's funny, but void* is an object pointer, it never points to void, it always points to an object
<K-ballo>
void is not an object type, so void* is special
<Yorlik>
Yup
<Yorlik>
Thats we void*++ is n't a thing
<Yorlik>
However - what i still do not really understand is the problem of east or west const
<Yorlik>
To me it looks like a matter of taste if you stay consistent (which I wasn'Ät)
<K-ballo>
in a nutshell: Type + const always gives you a const Type, where const + Type does not
<K-ballo>
using Type = int*; what's the type of `const Type`? is it `const int*`?
<Yorlik>
like a const T not being a T constant?
<K-ballo>
note I used + for a reason, as I said before it is a parsing issue
<K-ballo>
const T and T const are equivalent when T is the name of a type, but
<K-ballo>
when you write "const int*" the type T is not `int*`
<Yorlik>
int const * looks ambiguous, I agree
<K-ballo>
uh? there's nothing ambiguous about it
<Yorlik>
I mean - you could easily get confused is it a constant int or a constant pointer
<K-ballo>
you could?
<K-ballo>
const int* != const T
<Yorlik>
If const could be left ot right of the type
<K-ballo>
what's the type?
<Yorlik>
like Is it (int const)* or int (const *)
<K-ballo>
...
<Yorlik>
I mean look at this compiling example from before: int const const * a12= &i;
<Yorlik>
If you remove a const - which one is it?
<K-ballo>
I'm not positive redundant const is allowed by the standard...
<K-ballo>
I know one of the compilers has a bug in that area, but don't recall the specifics
<Yorlik>
It compiled - not sure abut the behaviopr though
<K-ballo>
given `using T = int*;`, what's the type of `const T`? what's the type of `T const`?
<Yorlik>
using cl
<Yorlik>
madness - lol
<K-ballo>
no such thing
<Yorlik>
but the type is an int, right?
<Yorlik>
I'd guess a pointer to a constant int
<K-ballo>
there is no *single* type, whenever there's a pointer there's at least two types
<K-ballo>
both `const T` and `T const` are a constant pointer to int
<Yorlik>
Doesn't the pointed to is kinda the dominating type?
<K-ballo>
I don't even know how "dominating" is defined
<Yorlik>
So the pointer dominates the overall type
<K-ballo>
the most important type is the type of the pointer itself
<Yorlik>
Because you say constant pointer
<K-ballo>
have you used member functions yet? struct X { void fun(); }; ?
<K-ballo>
how do you go about making one const?
<Yorlik>
Often
<Yorlik>
like void fun() const {} ?
<K-ballo>
what would happen if you add const on the left instead?
<Yorlik>
not changing any other member afaik
<Yorlik>
like void const fun() {}?
<K-ballo>
like that, yeah, is that a const member function?
<Yorlik>
I wonder if it would compile tbh
<K-ballo>
let's make it int const fun() {} if that makes it simpler to you
<K-ballo>
or const int fun() {}, no difference
<Yorlik>
I'd guiess it would return an int that is not allowed to be changed
<Yorlik>
But int would just be copied
<K-ballo>
so const means different things on the left than on the right, some times, right?
<Yorlik>
So - no effect probably?
<Yorlik>
I think in member functions it looks different to me
<K-ballo>
it's no different for member functions than it is for pointers
<Yorlik>
Like the ()const{}
<Yorlik>
I still have to learn more presicely about function types
<K-ballo>
const applies to the type immediately to the left.. (if there isn't one, west-const, then the rules get messy)
<Yorlik>
For lambdas I think it's [](){} with whats in it
<K-ballo>
some times const used on the left means the same thing than used on the right, it was added as an exception to the grammar, just because it could be done
<Yorlik>
I sind it confusing, that the member func const comes between the () and the body tbh
<K-ballo>
I don't see why you would, but I don't want to go there either
<Yorlik>
I mean func types are defined by ret value and params, right ?
<K-ballo>
the body isn't const after all
<Yorlik>
Its not part of the prototype anyways.
<Yorlik>
Since we declare only ret func(T params)
<Yorlik>
So - well - it actually makes sense to have it directly right of the ()
<Yorlik>
Today I was reading there are programmers who never ever use const ....
<Yorlik>
I don't want to know about their runtime situation
<Yorlik>
As much as I find const quite confusing in many ways, it can be learned , I believe
<K-ballo>
it's one of the things I miss most when in other languages
<Yorlik>
Before I started learning C++ again and for real the last manth I had 4 years of traight Lua behind me
<Yorlik>
Interestingly enough I hardly ever missed const and types - I only had wished for the performance boost they can bring
<Yorlik>
I just used Lua identifiers consistently, like a buzilt in type system.
<Yorlik>
I mean in my head
<zao>
I definitely don't mind immutable-by-default in Rust.
<Yorlik>
But before I had used Turbo pascal - another typed language
<zao>
So many nice things that C++ just can't support, for reasons.
<Yorlik>
My guess is that starting to learn programming with an untyped dynamic language is a really horrible idea
<Yorlik>
It corrupts the way you think.
<Yorlik>
Rust helped me to start thinking about mutability and ownership
<Yorlik>
I never got deep into Rust, but I like to just get these concepts into my head
<Yorlik>
Language really influences a lot how we think about the world. Same is true for programming, I believe.
<Yorlik>
Bad language = hampered thinking
hkaiser has quit [Quit: bye]
K-ballo has quit [Quit: K-ballo]
<lsl88>
Hi! Just wanted you to know that I finished with my goals about the manual and examples. Tomorrow I am ready to discuss ideas for the documentation
nikunj has quit [Remote host closed the connection]
Coldblackice_ has joined #ste||ar
Coldblackice has quit [Ping timeout: 245 seconds]
<heller>
simbergm: we should talk about the tutorial I think
<simbergm>
yep, we should
<simbergm>
heller ^
<simbergm>
did jbjnr write to you?
<heller>
No
<simbergm>
are you definitely coming?
<heller>
That's the plan, yes
<simbergm>
Ok, good
<simbergm>
jbjnr is away this week but we could do a call sometime this week without him
<simbergm>
he was stressing about everything
<simbergm>
you have time today or tomorrow?
<heller>
I can imagine
<heller>
Tomorrow would be better
<heller>
10 tomorrow?
<simbergm>
sure, that works
<heller>
Great
<heller>
I guess we need to finalize the content and how the hands on sessions are going to work
<heller>
aka on which computers
<heller>
My fau mail is down and I probably missed tons of mails
<heller>
Ok, fau mail should work again...
<heller>
simbergm: did Rolf send an email about participants and stuff in the last two or three weeks?
<hkaiser>
it's out of anybodies control at this point, just waiting...
<heller>
Bummer
<hkaiser>
nice!
<hkaiser>
Dr. Heller!
<heller>
Indeed
<hkaiser>
you did it
<heller>
Now I just have to get my shit back together and join hpx development again ;)
<heller>
The upcoming tutorial is perfect there
<heller>
hkaiser: and all thanks to you ;)
<heller>
Do you have time/energy to restart our weekly calls?
<hkaiser>
I'd love to
<heller>
Great!
<heller>
I think I can do tomorrow at 21:00 my time
<hkaiser>
heller: that should work, I'm glad you want to revive those calls
<heller>
Absolutely, I feel bad about the radio silence of the last months :/
<hkaiser>
no worries, all is well
* Yorlik
waves to heller
* heller
waves back
<Yorlik>
heller: Great to see you're still around after getting a job.
<heller>
I'm trying...
mdiers_ has quit [Remote host closed the connection]
auriane has joined #ste||ar
mdiers_ has joined #ste||ar
K-ballo has joined #ste||ar
<hkaiser>
mdiers_: yt?
<mdiers_>
hi
<hkaiser>
hey
<hkaiser>
mdiers_: your t-shirt is in the mail, should arrive soon
<mdiers_>
Thank you very much for the honor ;-)
<hkaiser>
lol
<hkaiser>
it's well deserved
diehlpk has joined #ste||ar
<mdiers_>
i also have a few changes to the slurm environment i would like to bring back. i would be happy if someone could have a look at it and test what adjustments i've made to make it work in our heterogeneous environment.
<mdiers_>
unfortunately there have already been some changes by our dr. heller in this area.
<hkaiser>
mdiers_: ok, I hope heller has some time to look into this
<heller>
I guess you have to bring it up to speed and submit another pr
hkaiser has quit [Quit: bye]
<mdiers_>
heller: i can try to understand your changes and then adopt them
<mdiers_>
heller: but I won't find time until the next few days.
<heller>
Sure, whenever you have time is fine
hkaiser has joined #ste||ar
diehlpk has quit [Remote host closed the connection]
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 252 seconds]
diehlpk has joined #ste||ar
rtohid has joined #ste||ar
<diehlpk>
rtohid, see pm
<diehlpk>
hkaiser, Is the operation bell meeting is setup?
<diehlpk>
I try to call in via phone and the meeting is not started yet
<diehlpk>
parsa, ?
<hkaiser>
diehlpk: I don't know, sorry
<hkaiser>
I'm in a different meeting, can't join the OB call
diehlpk has quit [Ping timeout: 250 seconds]
nikunj97 has joined #ste||ar
auriane has quit [Quit: bye]
<lsl88>
hi!
<hkaiser>
hiho
<lsl88>
shall we discuss the documentation?
<lsl88>
parsa:?
<parsa>
lsl88: hello!
<lsl88>
hi :)
<parsa>
so how is the proposal going?
<lsl88>
I finished reading the whole manual
<parsa>
okay, and what do you think of it?
<lsl88>
I find that for newcomers it is difficult to follow. I've been sending some pull requests with typos
<lsl88>
and yesterday for instance I was thinking about the optimization chapter, tables are broken and maybe the content there could be restructured and for instance, I was thinking of not using tables to solve it.
<lsl88>
I also wanted to know, how much do newcomers know beforehand about HPX and HPC?
<parsa>
lsl88: thanks for the editing fixes!
<parsa>
lsl88: unless they're just curious they have a need for hpx
<parsa>
which means they have some application and they want to extract a lot of parallelism by using HPX
<lsl88>
you are welcome :)
<lsl88>
oh, so they already have a prior knowledge then, right?
<parsa>
they may not, but they'll learn while they writing their applications
<parsa>
write*
<lsl88>
I see
<lsl88>
are there any chapters that you prefer working on?
<lsl88>
that maybe users had asked more questions about?
<parsa>
you could look at "Optimizing HPX applications" or look into writing a tutorial about performance debugging
<parsa>
we also have a bunch of video presentations and tutorials that have material not covered in the documentation. adding them to the documentation is going to be helpful to users
<lsl88>
oh I see, while I was reading the manual I thought about adding extra information, but reading the abstract I thought that you just wanted to restructure the available material.
<parsa>
cool! what do you have in mind?
<lsl88>
I have one example of this. Futures are used almost everywhere, but the concept is covered in detail in the first example
<lsl88>
not in the manual
<lsl88>
shall I share links here?
<parsa>
sure
<lsl88>
I have just found the videos
<lsl88>
I have some ideas but regarding the whole manual, I don't know if that is fine
<parsa>
i don't think there is a particular reason for why it is not covered in depth before the first example (i'm assuming you're talking about section 2.2.5 Writing task-based applications). please feel free to propose changes
<lsl88>
oh thank you, I am kind of shy at the beginning
<lsl88>
and I don't know how much you would like to include in the manual
<lsl88>
I feel I am talking about too many sections
<lsl88>
or small topics about all of them
<lsl88>
I don't know if that is right
<parsa>
we're just discussing what to do here. don't be afraid to talk about any subject. we'll do what we can to help you with HPX
<lsl88>
ok :)
<parsa>
i'm not sure what is too much at this point. add what you would prefer to work on to the proposal. we'll hammer out the details
<lsl88>
what I see in general with the manual -not the whole documentation- is that some concepts are assumed
<lsl88>
something that has just come to my mind is expanding the Terminology section and add links inside the manual to new definitions there
<lsl88>
We have futures, queues, barriers and object_semaphores. Does the reader have to know what they are beforehand?
<lsl88>
If not, their definitions could be added to the Terminology section outside the manual, and have a link, so that readers who are experienced can go on reading, and those who are somewhat lost can click the word and read what they are/how they work, like with parcels, actions, components and so on. WDYT?
<parsa>
we didn't invent them. they're computer science terms. so we shouldn't spend too much time introducing them to users, but including a brief introduction for users who may not know them is a nice addition
Karame has joined #ste||ar
<parsa>
sure, we can add links to definitions elsewhere on the web
<lsl88>
uhm then is it fine working on different aspects? maybe restructuring a chapter of fixing what's broken there, adding links to definitions in different chapters of the manual or content from the videos that is not covered, writing a tutorial on sth like you proposed before? or is that too much?
<lsl88>
and also some fields of the table have the same information
<parsa>
lsl88: yes all of what you've suggested is fine
<parsa>
what's wrong with that table, btw?
<lsl88>
tables are bigger than the page
<parsa>
it exceeds they gray background a bit, but the contents seem fine
<lsl88>
I think that these tables could be polished, for example, you have <operation> and <connection type> with their possible values all over the table
<lsl88>
and maybe the description field should be the second one, so that the reader has the counter and what it does next to it.
<lsl88>
in the case of AGAS performance counters the value of the Description and Parameters are exchanged
<diehlpk_work>
lsl88, Could you write down in your google document some bullet points for each section you would work on?
<lsl88>
diehlpk_work: sure!
<lsl88>
just bullet points?
<diehlpk_work>
simbergm, parsa and I have will have a look and ask for more details and we can nail down your proposal
<diehlpk_work>
Yes, we do bullet points first, discuss them, and later once we decided what you will do, you can write full text
<lsl88>
ok :) I am writing just the bullet points with a brief description of what they mean
<diehlpk_work>
let us try to have some content till Thursday and you will have enough time to polish the content
<lsl88>
I wrote the bullets
<lsl88>
I will watch the videos now
hkaiser has quit [Quit: bye]
<diehlpk_work>
lsl88, Write tutorials to complement the existing manual.
<diehlpk_work>
Could you write more details about this one?
<diehlpk_work>
Improve the existing manual. Do you want to focus on some sections or on the whole manual?
hkaiser has joined #ste||ar
<diehlpk_work>
hkaiser, Can you add GSoD to our channel's description?