|
Community |
Community -> PublicMeetings -> 27th of January 2016WhenTopicScripting variables in OpenSIPS 3.x Problems to be addressedList of the current issues with OpenSIPS scripting variables:
Conclusions
IRC Logs
[16:59] == mode/#opensips [+o bogdan_vs] by ChanServ
[17:00] == bogdan_vs changed the topic of #opensips to: Public Meeting - script variables
[17:01] <@bogdan_vs> To read on topic - http://lists.opensips.org/pipermail/users/2016-January/033587.html
[17:01] <@bogdan_vs> Hi all
[17:01] <@bogdan_vs> and welcome
[17:01] <@bogdan_vs> :)
[17:02] <lirakis> hello! thanks for having the meeting
[17:02] <@bogdan_vs> I know it is early for some of you
[17:02] == fs_noobster [~greekman0@96.88.49.66] has joined #opensips
[17:02] <@bogdan_vs> next time we will try to adjust for a better time window to make more people happy ;)
[17:02] <@bogdan_vs> so.....
[17:03] <@bogdan_vs> the discussion is about the new upcoming 3.x branch
[17:03] <@bogdan_vs> where the cfg changes + reload will be pushed
[17:03] <@bogdan_vs> and the topic is about the scripting variables...
[17:04] <lirakis> interesting - so are there specific concerns or considerations relating to variable scoping with the 3.x changes?
[17:04] <@bogdan_vs> many of us (including myself) had hard times due inconsistency in working with vars
[17:05] <@bogdan_vs> lirakis: we are good (imho) when comes to the scope of the vars
[17:05] <lirakis> i have definitely been bitten by not knowing how to appropriately test for an "empty" variable
[17:05] <@bogdan_vs> like we have vars per transaction, per dialog, globals...
[17:05] <lirakis> i say empty because its not been clear if its null <null> or ""
[17:05] <@bogdan_vs> exactly...
[17:05] <@bogdan_vs> the problem comes with the values of these vars
[17:06] <@bogdan_vs> as they have different approaches on NULL, if can be int or str....etc
[17:06] <@bogdan_vs> like avps (transaction level) do not support NULL
[17:06] <lirakis> i know the internals of how variables have been stored has changed over time, specifically to their typing
[17:06] <@bogdan_vs> or the dialog vars can be only string
[17:06] <lirakis> as you just mentioned .. str, int etc.
[17:07] <lirakis> its like the variables are not fully encapsulated... they have some ... finicky side effects depending on implementation
[17:07] <@bogdan_vs> even more....we have his json vars...which are focusing on the value
[17:07] <lirakis> right
[17:07] <@bogdan_vs> not on scope
[17:07] <vlad-paiu> a little bit offtopic maybe, related to the scope of vars.. in certain cases, during the processing of the CANCEL I had to access some $avp from the INVITE context.. but it doesn't seem there's any way to do that
[17:07] <lirakis> is cancel part of the same transaction? .... i know its a bit "special"
[17:07] <lirakis> but yea i dont want to get too far off topic
[17:07] <@bogdan_vs> vlad-paiu: well, if I'm not wrong CANCEL is a separate transaction
[17:08] <lirakis> ^
[17:08] <vlad-paiu> yep, it is
[17:08] <@bogdan_vs> it is not an argument, but a statement :D
[17:08] <lirakis> so i actually dont have a "problem" with the different scope
[17:08] <lirakis> i think it can be convenient to have things scoped transactionally, at the dialog, or at the script level
[17:08] <@bogdan_vs> I had this problem while working with Liviu on the new siptrace engine
[17:08] <@bogdan_vs> sorry, not Liviu, with John
[17:08] <vlad-paiu> but think we could find a way to access stuff from the INVITE transaction.. might come in handy in certain cases
[17:09] <lirakis> i mean, you have to be careful obviously
[17:09] <@bogdan_vs> same problem, INVITE versus CANCEL
[17:09] <@bogdan_vs> there are ways :)
[17:09] <lirakis> but i think it is ... in the "spirit" of how opensips works to have variables that scope within their respective SIP elements
[17:09] <@bogdan_vs> the question is what we what to allow or not
[17:09] <lirakis> id say dont honestly
[17:09] <lirakis> avp's are transactional, if you want scope outside of a transaction, use a dialog value
[17:10] <@bogdan_vs> well, when come to scope, we can "define" what we need
[17:10] <@bogdan_vs> we may be RFC strict ....
[17:10] <lirakis> ok - so lets continue with this avp scope
[17:10] <lirakis> for the sake of discussion
[17:10] <@bogdan_vs> ...or go for the real life needs
[17:10] <@bogdan_vs> yeah :)
[17:10] <lirakis> how would you expand its scope if not just to the dialog level
[17:10] <@bogdan_vs> anyhow, most of the vars are scope oriented, while json are value oriented
[17:11] <lirakis> ... avp's are scoped transactionally ... **but also you can match on transaction**
[17:11] <lirakis> that seems hacky to me
[17:11] <@bogdan_vs> Liviu was mentioning his dirty tricks on how to pass a json via a route param
[17:11] <lirakis> sorry .. *you can also match the cancel transaction*
[17:11] <@bogdan_vs> or how to make a json dialog persistent
[17:12] <lirakis> so i have very little experience working with json vars in opensips
[17:12] <lirakis> ... so .. what is their .. scope?
[17:12] <@bogdan_vs> their scope is == var()
[17:12] <lirakis> im not sure i understand what "value oriented" means
[17:12] <lirakis> ok .. so its like a script var?
[17:12] <@bogdan_vs> but the value is a structures json where you can access sub-values based on the path
[17:12] <@bogdan_vs> (inside the json string)
[17:12] <lirakis> right
[17:13] <@bogdan_vs> var has just a dummy value...
[17:13] <lirakis> and they alias to some other structure in the back end implementation
[17:13] <@bogdan_vs> so we have vars oriented to a scope and vars oriented to vals
[17:13] <@bogdan_vs> but the combinations are limited by implementation right now
[17:14] <@bogdan_vs> like what certain vars can hold (as value)
[17:14] <@bogdan_vs> vars (as scope)
[17:14] <@bogdan_vs> like you cannot have $param() or $dlg_val() holding a json value
[17:14] <@bogdan_vs> (only as converted to string)
[17:15] <lirakis> right
[17:15] <@bogdan_vs> you cannot have a $dlg_val with an int
[17:15] <lirakis> i didnt know that heh
[17:15] <razvanc> perhaps we should have to differentiate between the type and the scope
[17:15] <@bogdan_vs> you cannot have an $avp with NULL
[17:15] <vlad-paiu> @bogdan_vs : yeah.. dlg_val with no int also sucks :D
[17:15] <@bogdan_vs> only $avp can have multiple values (or a list)
[17:15] <@bogdan_vs> (we can see lists as a special type of value)
[17:15] <lirakis> yeah ... i think the most glaring issue is the lack of consistency between the differently scoped variables
[17:16] <lirakis> regarding the types of values they can hold
[17:16] <@bogdan_vs> exactly
[17:16] <@bogdan_vs> which is first a nightmare (as you do not remember how each value can behave as value)
[17:16] <@bogdan_vs> and secondly as it is a limitation
[17:17] <razvanc> so, what I was saying earlier, is that each pseduo variable should designate the type of the value it stores
[17:17] <@bogdan_vs> personally I burned my aXX many times with the $var() test against NULL
[17:17] <razvanc> and then have a different indicator of the scope
[17:17] <lirakis> razvanc, that seems a little bit like a step backwards - at least from a users perspective
[17:18] <razvanc> for example in C, you declare a variable like [scope] [type] name;
[17:18] <lirakis> $var(s:t:"my value");
[17:18] <lirakis> seems like days of old
[17:18] <lirakis> where that var would be a string that is transactionally scoped
[17:18] <lirakis> i mean .. i guess it does make sense though to make it more declarative
[17:18] <@bogdan_vs> I'm more looking into perl/python model
[17:18] <lirakis> right where that is hidden from the user
[17:18] <lirakis> but that obviously makes things more complicated on the back end
[17:18] <razvanc> I was thinking like $(<scope>(int)) = 30;
[17:19] <@bogdan_vs> where you do not have to specify the type (as value)
[17:19] <@bogdan_vs> it is up to the assignments you do
[17:19] <vlad-paiu> razvanc: why would you have to explicitly pass it the type ?
[17:19] <razvanc> bogdan_vs: and only specify the scope?
[17:19] <lirakis> yeah i like the automatic typing - it does make it a bit ambiguous though is "1" and int or a string
[17:19] <@bogdan_vs> razvanc: better $scope(name) = (int) value;
[17:20] == sekil [~sekil@nat-73.net011.net] has quit [Quit: Leaving.]
[17:20] <@bogdan_vs> if it is ambiguous (by simply looking at the value, you can have a cast operator
[17:20] <vlad-paiu> well.. "1" is a string, 1 is an int :))
[17:20] <@bogdan_vs> like $scope(name) = (json)"{.....}"
[17:20] <lirakis> right
[17:20] <@bogdan_vs> versus $scope(name) = "{.....}"
[17:20] <@bogdan_vs> that will be a simple string ^^^
[17:21] <razvanc> if we do like this, then we'll have to somehow differentiate between pseudo-variables and variables
[17:21] <lirakis> what is the difference ?
[17:21] <lirakis> you mean like .. built in vars $rd
[17:21] <@bogdan_vs> well, that will be at implementation level
[17:21] <razvanc> lirakis: yes
[17:21] <razvanc> for example $rd
[17:21] <@bogdan_vs> the pseudo-vars will stay as they are....
[17:21] <razvanc> is it a scope? or a pvar
[17:22] <@bogdan_vs> $rd is not a real variable
[17:22] <lirakis> right
[17:22] <@bogdan_vs> it is a way of accessing parts of the sip msg
[17:22] <razvanc> if the pvars will stay the same, then we don't have a problem with the scope
[17:22] <lirakis> i would assume pvars are script level
[17:22] <razvanc> we only have with the value
[17:23] <fs_noobster> quite honestly I don't see what all the fuss is about... I remember every variable/scope/capability in opensips... I thought that was a requirement to take part in these discussions <sigh>
[17:23] <lirakis> yeah ive not run into issues with pvars - though its not clear what the value is if some thing is not set
[17:23] <razvanc> yes, to be honest my only concerns were related to the values a pvar can have
[17:23] <lirakis> fs_noobster, i mean .. ive been using opensips for 5+ years and i didnt even know about $shv till recently
[17:23] <razvanc> I've never doubt about the scope
[17:23] <lirakis> heh
[17:23] <@bogdan_vs> fs_noobster: remembering is only one part
[17:23] <lirakis> yeah the scope is not an issue to me
[17:24] <fs_noobster> :P
[17:24] <lirakis> the inconsistency between what types they can hold IS an issue IMO
[17:24] <@bogdan_vs> fs_noobster: now you do not have a solution for a dialog variable holding an integer
[17:24] <lirakis> string transformations to the rescue!
[17:24] <fs_noobster> lol
[17:24] <razvanc> it can be done, but that's not so nice
[17:24] <razvanc> nor efficient
[17:24] <lirakis> yeah heh
[17:25] <razvanc> I agree with bogdan_vs
[17:25] <@bogdan_vs> lirakis: with a unlimited amount of transformation, you may solve any current issues :)
[17:25] <lirakis> i was joking
[17:25] <fs_noobster> honestly lirakis, I thought at the beginning... why not just make everything strings, then based on what you store, you know how to convert the dang thing
[17:25] <fs_noobster> create your own scope
[17:25] <lirakis> yeah i mean thats just doing effectively the same thing as making it declarative
[17:25] <lirakis> well you arent creating your own scope
[17:25] <lirakis> just typing everything
[17:26] <fs_noobster> not literally no
[17:26] <fs_noobster> but by what you store and how you define you kinda are
[17:26] <fs_noobster> my point gentlemen is this...
[17:26] <fs_noobster> and I say this from learning much from documentation
[17:26] <@bogdan_vs> fs_noobster: holding everything as str is not optimal and it is not clear
[17:26] <fs_noobster> be careful in what you are venturing into here
[17:26] <@bogdan_vs> too many conversions....
[17:27] <fs_noobster> as we are already at a disadvantage from a documentation perspective
[17:27] <fs_noobster> that was my point :)
[17:27] <@bogdan_vs> and also you may not have enough info (to interpret the str value) at the evaluation time
[17:27] <fs_noobster> I'll pipe down
[17:28] <fs_noobster> agree it's not the optimal solution (waves white flag)
[17:28] <@bogdan_vs> to be honest, I 'm looking at this more from the user perspective
[17:28] <@bogdan_vs> new users being puzzled and confused about all the vars we have now in the opensips cfg
[17:29] <@bogdan_vs> they should have a easy learning / understanding on how to use vars in script
[17:29] <lirakis> so ... that is my concern about making the scope and type declarative
[17:29] <lirakis> i remember when i was starting out, avp's were not automatic
[17:29] <razvanc> lirakis: I wasn't saying we should make them declarative
[17:29] <lirakis> and it was a confusing thing to be doing stuff like $avp(i:foo)=1;
[17:29] <@bogdan_vs> that was on names
[17:30] <lirakis> my only point is i would like to avoid "going back" to that
[17:30] <@bogdan_vs> so, if we keep the scopes predefined....
[17:31] <@bogdan_vs> and use declaration on values, only if there is an ambiguity
[17:31] <fs_noobster> or how about $avps() $avpi()
[17:31] <@bogdan_vs> and if you want to put a json into the avp ?
[17:31] <@bogdan_vs> $avpj() ?
[17:31] <lirakis> i like what razvanc and bogdan_vs suggested earlier: scope type $var(name)
[17:32] <fs_noobster> sure
[17:32] <fs_noobster> why not?
[17:32] <fs_noobster> maybe leave $avp() as is , a string
[17:32] <lirakis> the format of : scope type $var/avp(name) is familiar because that is how MANY languages do it already
[17:32] <razvanc> to be honest, I'd rename avp to tm, or something like that
[17:32] <fs_noobster> and do $avpx() as the declaritive bit
[17:32] <razvanc> a special variable that can hold anything
[17:32] <razvanc> int, string, json, list, just like in python
[17:32] <@bogdan_vs> fs_noobster: avp can be now string or int
[17:33] <lirakis> razvanc, yea i guess if you can declare the scope, "avp" is not needed
[17:33] <fs_noobster> right
[17:33] <@bogdan_vs> Alien Versus Predator !!
[17:33] <@bogdan_vs> AVP
[17:33] <razvanc> and where's the transaction there :))?
[17:33] <fs_noobster> I like the new format $avp(<named variable>)
[17:34] <fs_noobster> agree with likaris "$avp(i:foo)=1;"
[17:34] <fs_noobster> that would be going backward
[17:34] <razvanc> I don't :)
[17:34] <fs_noobster> I'll send you a jar of penut butter if you vote with us
[17:34] <fs_noobster> lmao
[17:34] <lirakis> razvanc, what about what i just mentioned: scope type $var(name)=val; ?
[17:35] <lirakis> tm str $var(foo)="bar";
[17:35] <lirakis> its super clear about what the scope is, and what the value holds
[17:36] <lirakis> and the format is similar to other languages to avoid "confusion"
[17:37] <lirakis> *crickets*
[17:37] <fs_noobster> apparantly razvan has enough penut butter :-/
[17:37] <razvanc> :))
[17:38] <razvanc> the idea with the scope and type came from C
[17:38] <razvanc> where the type is explicit
[17:38] <razvanc> and the scope has a default
[17:38] == Hydrosine [~Hydrogone@unaffiliated/hydrosine] has quit [Ping timeout: 240 seconds]
[17:38] <lirakis> other languages (java etc) are similar, in that they declare a public, private etc. for scope
[17:38] <razvanc> exactly
[17:38] <lirakis> public int myInt=1;
[17:39] <razvanc> my point was that the name of the pvar should be either the scope, either the type
[17:39] <razvanc> not both :)
[17:39] <lirakis> ... the "name" ?
[17:39] <vlad-paiu> I think all the info should be all together somehow.. cause later in the script when you'd access $var(foo) , you'd want to quickly be able to know if you, as the script writer, are using it in the right context
[17:39] <razvanc> vlad-paiu: that's exactly my point
[17:39] <vlad-paiu> str $tm(foo)="bar" seems better to me
[17:39] <lirakis> vlad-paiu, vs. doing static type checking on startup?
[17:39] <lirakis> i see
[17:40] <razvanc> I'd rather go with the Python way :)
[17:40] <razvanc> not specify the type, and the scope should be embedded in the name
[17:41] <lirakis> python .. doesnt have explicit typing?
[17:41] <razvanc> my problem is what happens with pvars like $rd
[17:41] <lirakis> i see
[17:41] <razvanc> 'cause that's not a scope
[17:41] <lirakis> so automatic typing, and name the scope
[17:41] == Hydrosine [~Hydrogone@185.47.1.1] has joined #opensips
[17:41] <lirakis> $tm(foo)=1; or $tm(bar)="mystring"
[17:41] <razvanc> lirakis: yes
[17:41] <lirakis> i mean i like automatic typing for sure
[17:42] <fs_noobster> or how about something like this:
[17:43] <fs_noobster> str $myvar
[17:43] <lirakis> razvanc, would the pvars need to change at all ?
[17:43] <fs_noobster> int $myvar2
[17:43] <fs_noobster> json $myvar3
[17:43] <lirakis> fs_noobster, where is the scope on those though?
[17:43] <fs_noobster> now anything in $myvar(<name>) is always a str
[17:44] <fs_noobster> and $myvar1(<name>) always and int
[17:44] <@bogdan_vs> what about this:
[17:44] <fs_noobster> etc, etc
[17:44] <@bogdan_vs> (just back from the whiteboard)
[17:44] <@bogdan_vs> $rd -> $msg(rd)
[17:44] <@bogdan_vs> to make it consistent as scope
[17:44] <@bogdan_vs> $du -> $msg(du)
[17:44] <lirakis> i like that well enough
[17:44] <razvanc> me too :)
[17:44] <fs_noobster> 3
[17:44] <vlad-paiu> 4
[17:44] <@bogdan_vs> in this case, all vars will have a clear scope
[17:45] <@bogdan_vs> and $ts (timestamp) => $opensips(ts) or $internal(ts)
[17:45] <lirakis> so it would be ... $msg(var) ... $tm(var) .... $dlg(var) ?
[17:45] <@bogdan_vs> whatever
[17:45] <razvanc> lirakis: yes
[17:45] <@bogdan_vs> $script()
[17:45] <@bogdan_vs> $global()
[17:45] <@bogdan_vs> for $shv
[17:46] <lirakis> right
[17:46] <lirakis> yeah i mean if we had that + automatic typing
[17:46] <lirakis> that would be great
[17:47] <lirakis> though im not sure how youd ... figure out if some thign should be json vs. string
[17:48] <razvanc> we could probably have a type operator :)
[17:48] <razvanc> or something like that
[17:48] == DanB_ [~DanB@port-92-194-82-77.dynamic.qsc.de] has joined #opensips
[17:48] <lirakis> like you could have the cast operators to clarify if you wanted
[17:48] <razvanc> sure, that's mandatory
[17:48] <lirakis> (json) $tm(foo) = "{asdf=>"bla"}"
[17:49] <lirakis> or something
[17:49] <@bogdan_vs> actually: $tm(foo) = (json)"{asdf=>"bla"}"
[17:49] <lirakis> sure
[17:49] <@bogdan_vs> :)
[17:49] <liviuc> $tm(foo) = json("{asdf=>"bla"}") <------ Python style
[17:49] <lirakis> so were converting opensips scripting to python
[17:50] <lirakis> :P
[17:50] <lirakis> he he
[17:50] <vlad-paiu> noooo
[17:50] <liviuc> what I said above is both Perl and Python...
[17:50] == DanB__ [~DanB@port-92-194-106-136.dynamic.qsc.de] has joined #opensips
[17:50] <razvanc> let's do it OpenSIPS' way ;)
[17:50] == DanB [~DanB@port-92-194-192-212.dynamic.qsc.de] has quit [Ping timeout: 260 seconds]
[17:50] <razvanc> don't know what's that :))
[17:50] <lirakis> ok well - im sold on the proposed idea
[17:51] <@bogdan_vs> one more thing :)
[17:51] <@bogdan_vs> how do we deal with multiple values
[17:51] == Cippenham [~Cippenham@mail.eph.co.uk] has joined #opensips
[17:51] <@bogdan_vs> we definitly need something like that
[17:51] <@bogdan_vs> like we have for avp() now
[17:51] <vlad-paiu> do we want everything to have multiple values ?
[17:51] <lirakis> id say yes
[17:51] <lirakis> id say get rid of avp's since we are defining $tm() $dlg() etc
[17:52] <lirakis> and make another type similar to the json definition
[17:52] <@bogdan_vs> then we need to be careful on assignments..
[17:52] <liviuc> "list" and "json"
[17:52] <lirakis> so youd do an array
[17:52] <lirakis> ^
[17:52] <lirakis> $tm(mylist)= list("item1,item2,item3");
[17:52] <@bogdan_vs> assigning a new value means adding to the stack or means changing it ??
[17:52] <lirakis> id say its replacement
[17:53] <liviuc> @lirakis: think you meant: $tm(mylist)= list("item1", "item2", "item3");
[17:53] <vlad-paiu> lol
[17:53] == DanB_ [~DanB@port-92-194-82-77.dynamic.qsc.de] has quit [Ping timeout: 240 seconds]
[17:53] <vlad-paiu> true :)
[17:53] <lirakis> unless it supports the + operator
[17:54] <lirakis> $tm(mylist)=$tm(mylist)+"newitem";
[17:54] <vlad-paiu> default should be replacement.. think so too
[17:55] <@bogdan_vs> and := should be "add" ?
[17:55] <lirakis> no it should replace it i think
[17:55] <jarrod> crap, ive missed so much
[17:55] <lirakis> bogdan_vs, $tm(mylist)=$tm(mylist)+"newitem"
[17:55] <lirakis> jarrod, 4 minutes left
[17:56] <lirakis> ;)
[17:56] <liviuc> ^ "+" operator is more than fine
[17:56] <@bogdan_vs> lirakis: hmm....that will highly depend on the data type
[17:56] <vlad-paiu> I don't like it :(
[17:57] <@bogdan_vs> what if the value is string and you actually want to do a concat ?
[17:57] <vlad-paiu> right
[17:57] <@bogdan_vs> ++ on vlad-paiu !
[17:57] <liviuc> @vlad-paiu: not many options... either "." (PHP) or some append() ugly function
[17:57] <lirakis> bogdan_vs, wouldnt you have to cast the list
[17:57] <@bogdan_vs> it should be much simpler to have somehow solved at operator level
[17:58] <@bogdan_vs> ...to have it....
[17:58] <lirakis> $tm(concatedlist) = "somestring"+ (string)$tm(mylist)
[17:58] <@bogdan_vs> maybe "+=" rather than "=" for adding new values
[17:58] <lirakis> i mean i think there are two options .. create special operators for dealing with lists, or use + and = they way all other vars use them
[17:59] <lirakis> bogdan_vs, yea
[17:59] <lirakis> i think that makes sense
[17:59] <lirakis> but that is different than all other variables
[17:59] <lirakis> like .. do strings contact when you do += now ?
[17:59] <@bogdan_vs> no
[17:59] <lirakis> i was just trying to be consistent
[17:59] <@bogdan_vs> it will and a new value
[17:59] <@bogdan_vs> we do not have += now
[18:00] <liviuc> although the parser handles it :D
[18:00] <@bogdan_vs> really :O ???
[18:00] <@bogdan_vs> shXt .....
[18:00] <@bogdan_vs> anyone using it ??
[18:00] <@bogdan_vs> if not, it means we do not have it :P !
[18:01] <@bogdan_vs> ok, times up
[18:01] <lirakis> lol
[18:01] <@bogdan_vs> :)
[18:01] <lirakis> ill have to check out += now
[18:01] <@bogdan_vs> and I guess all the main aspects were discussed
[18:01] <liviuc> you'll probably end up digging through code :)
[18:01] <lirakis> hehe
[18:01] <@bogdan_vs> about scope, values, casting, multiple vals
[18:02] <@bogdan_vs> anything missing here ?
[18:02] <lirakis> we didnt really cover anything about null etc.
[18:02] <vlad-paiu> well.. everything should handle NULL
[18:02] <lirakis> id say that all values should be able to be null
[18:02] <vlad-paiu> there, covered :)
[18:02] <lirakis> yea vlad-paiu
[18:02] <@bogdan_vs> NULL should be supported by all vals
[18:03] <lirakis> ok good
[18:03] <@bogdan_vs> vars
[18:03] <@bogdan_vs> :)
[18:03] <liviuc> yes :) any language has a NULL or a None
[18:03] <lirakis> glad we are all in agreement ;)
[18:03] <@bogdan_vs> :)
[18:03] <liviuc> also, we should decide how boolean operators work on lists... probably steal more from Python
[18:04] <@bogdan_vs> ok, so we will wrap up all these on the wiki page
[18:04] <@bogdan_vs> and re-post the link
|
Page last modified on January 28, 2016, at 07:29 PM