val gitHeadCommitSha = taskKey[String]("Determines the current git commit SHA")
gitHeadCommitSha := Process("git rev-parse HEAD").lines.head
In the above code, I suppose = creates a key (which I suppose is analogous to declaring a variable and := declares a setting. So does SBT allow declaring a key and a setting of the same name? OR is gitHeadCommitSha a task?
gitHeadCommitSha is a value of type TaskKey[String], while gitHeadCommitSha := Process("git rev-parse HEAD").lines.head is a value of type Setting[Task[String]].
In terms of = vs :=, = is the scala primitive to define a binding, while := is a method on TaskKey (and the other keys) to define a setting (which you typically don't assign to a variable).
So what that code does is define a task key of name "gitHeadCommitSha" and then set the value of that key.
Related
I am migrating some code from Delphi 5 to a modern platform. Currently I have the compiled code (which works in my environment) and the source code (which cannot be compiled in my environment). This means I can't really experiment with the code by changing it or inserting breakpoints or dumping values. In looking at one particular passage of code, I see that one Procedure (ProcedureA) is calling another (ProcedureB) and passing in parameters that must be by reference, since otherwise ProcedureB would have no effect. It's my understanding that a var prefix must be added to parameters in a Procedure's parameter list in order for them to be passed by reference, but this is not being done here. One of the parameters, though, is of type TList, which I know to be essentially an array of pointers. My question is: are parameters of type TList (as well as others having to do with pointers) implicitly passed by reference?
Here's the code:
Procedure ProcedureB(PartyHeaderInformationPtr : PartyHeaderInformationPointer;
PartyHeaderTable : TTable;
_PrisonCode : String;
_FineType : TFineTypes;
PartyHeaderInformationList : TList);
begin
with PartyHeaderInformationPtr^, PartyHeaderTable do
begin
AssessmentYear := FieldByName('TaxRollYr').Text;
PartyType := FieldByName('PartyType').Text;
PartyNumber := FieldByName('PartyNo').AsInteger;
PrisonCode := _PrisonCode;
FineType := _FineType;
end; {with PartyHeaderInformationPtr^ ...}
PartyHeaderInformationList.Add(PartyHeaderInformationPtr);
end; {AddPartyHeaderPointerInformation}
{=================================================================}
Procedure ProcedureA(PartyHeaderTable : TTable;
PartyDetailTable : TTable;
PartyHeaderInformationList : TList);
var
Done, FirstTimeThrough : Boolean;
PrisonPartyFound, JunglePartyFound : Boolean;
PrisonPartyYear, PrisonCode, PartyType : String;
PartyHeaderInformationPtr : PartyHeaderInformationPointer;
begin
PartyHeaderTable.Last;
PrisonPartyYear := '';
PrisonPartyFound := False;
JunglePartyFound := False;
Done := False;
FirstTimeThrough := True;
repeat
If FirstTimeThrough
then FirstTimeThrough := False
else PartyHeaderTable.Prior;
If PartyHeaderTable.BOF
then Done := True;
If not Done
then
begin
PartyType := PartyHeaderTable.FieldByName('PartyType').Text;
If ((not JunglePartyFound) and
((PartyType = 'MU') or
(PartyType = 'TO')))
then
begin
JunglePartyFound := True;
New(PartyHeaderInformationPtr);
AddPartyHeaderPointerInformation(PartyHeaderInformationPtr,
PartyHeaderTable,
'', ltPlace,
PartyHeaderInformationList);
end; {If ((not JunglePartyFound) and ...}
end; {If not Done}
until Done;
end; {FillPartyHeaderInformationList}
Yes.
In Delphi, classes are reference types.
Every variable of type TBitmap, TList, TButton, TStringList, TForm etc. is nothing but a pointer to the object, so an object is always passed "by reference". It is only this address, this native-sized integer, that is given to the called routine.
Consequently, even without var, the called routine can alter the object since it, like the caller, has the address to it. But the pointer itself is passed by value, so if the called routine alters the parameter pointer to point to a different object, the caller will not see that; only the called routine's copy of the address is changed. With var, the pointer itself is passed by reference, so the called routine can change that too: it can change the original object, and it can make the caller's variable point to a different object, if it wants to.
On the other hand, value types like integers, booleans, sets, static arrays, and records are passed by value, so -- without any parameter decoration such as var -- the called routine gets a copy, and any changes made are only made to that copy. The caller will not see its variable being modified. If you use a var parameter, however, the variable will be passed by reference.
So, in your case, it has nothing to do with TList being a "list" or being something that "contains pointers". It's about TList being a class.
In GeoDMS, a geographic coding language by Object Vision, I cannot run code in GeoDmsRun.exe, which I could run without problems in GeoDmsGui.exe. The problem is that it cannot find the parameter 'Values' which is indeed not defined, but apparently implicit somewhere in GeoDMS. The GUI could find this parameter.
I tried defining the Values that lookup is looking for explicitly using
attribute<uint32>values1:=values;
But that didn't work. It would be best to get this lookup functionality without having to use any implicit variables, but how to do that?
Code:
unit<uint32> heatNet2 := unique(buildingWithHeatDemand/roadID)
, dialogType = 'map'
, dialogData = 'geometry'
{
attribute<rdc> geometry(arc) := lookup(values,input/geographic/roads/geometry);
}
Version: 7177
Thanks for helping!
The unique(D->V) operator indeed defines an attribute E->V with the name values of the resulting unit E that maps that resulting unit E to the found values of V. GeoDmsRun.exe should process scripts the same way as GeoDmsGui.exe does, so it is a good idea to report this as issue at http://www.mantis.objectvision.nl.
Meanwhile you can try to define the values attribute explicitly:
unit<uint32> heatNet2 := unique(buildingWithHeatDemand/roadID)
, dialogType = 'map'
, dialogData = 'geometry'
{
attribute<input/geographic/roads> values(heatNet2);
attribute<rdc> geometry(arc) := lookup(values,input/geographic/roads/geometry);
}
The now explicitly defined values will refer to the attribute of the result of the unique operator.
I have this simple command that changes the value of myBoolSetting:
commands += Command("mycommand") {
state ⇒ (Space ~> Bool).?
} { (state, arg) ⇒
val b = arg.getOrElse(true)
Project.extract(state).append(Seq(myBoolSetting in Global := b), state)
}
When I change invoke it does change myBoolSetting but I lose any setting whose value has been changed by means of the set command.
> set myStringSetting := "new value"
> myCommand false
In this example, the value of myStringSetting has been lost and has its default value.
How can I change a setting and keep manual changed settings?
UPDATE:
Found related question: Why sbt.Extracted remove the previously defined TaskKey while append method?, but seems not to work in my case.
Modified code:
commands += Command("mycommand") {
state ⇒ (Space ~> Bool).?
} { (state, arg) ⇒
val b = arg.getOrElse(true)
val session = Project.session(state)
val state2 = Project.extract(state).append(Seq(myBoolSetting in Global := b), state)
SessionSettings.reapply(session, state2)
}
I might only partially answer your question.
The reason for losing myStringSetting new value is that myCommand reloads a session effectively leaving you with what you have already in build.sbt-like files and what the command itself set. You simply drop the value while reloading the session.
It is similar to doing set scalaVersion := "2.11.7" and reload afterwards. scalaVersion becomes the default Scala version you had in sbt configuration.
You now know why you lose the value. If you want to retain the value you'd have to save the current session session save and execute your command. You need to add session save to your command.
I'm getting this return value from a function call in the "reflect" package:
< map[string]string Value >.
Wondering if I can access the actual map inside the return value and if so, how?
EDIT:
So this is where I'm making the call which returns the Value object.
It returns [< map[string]string Value >] to which I grab the first object in that array. However, I'm not sure how to convert [< map[string]string Value >] into a regular map.
view_args := reflect.ValueOf(&controller_ref).MethodByName(action_name).Call(in)
Most reflect Value objects can be converted back to a interface{} value using the .Interface() method.
After obtaining this value, you can assert it back to the map you want. Example (play):
m := map[string]int{"foo": 1, "bar": 3}
v := reflect.ValueOf(m)
i := v.Interface()
a := i.(map[string]int)
println(a["foo"]) // 1
In the example above, m is your original map and v is the reflected value. The interface value i, acquired by the Interface method is asserted to be of type map[string]int and this value is used as such in the last line.
To turn the value in a reflect.Value into an interface{}, you use iface := v.Interface(). Then, to access that, you use a type assertion or type switch.
If you know you're getting a map[string]string the assertion is simply m := iface.(map[string]string). If there's a handful of possibilities, the type switch to handle them all looks like:
switch item := iface.(type) {
case map[string]string:
fmt.Println("it's a map, and key \"key\" is", item["key"])
case string:
fmt.Println("it's a string:", item)
default:
// optional--code that runs if it's none of the above types
// could use reflect to access the object if that makes sense
// or could do an error return or panic if appropriate
fmt.Println("unknown type")
}
Of course, that only works if you can write out all the concrete types you're interested out in the code. If you don't know the possible types at compile time, you have to use methods like v.MapKeys() and v.MapIndex(key) to work more with the reflect.Value, and, in my experience, that involves a long time looking at the reflect docs and is often verbose and pretty tricky.
why this not working ??
with Win32.Winbase; use Win32.Winbase;
with Win32; use type Win32.BOOL;
with Win32.Winnt; use type Win32.Winnt.pHandle;
procedure Welcome is
Startup_Info : aliased STARTUPINFO;
SecurityAttribute : aliased PSECURITY_ATTRIBUTES;
begin
Startup_Info.dwFlags := 123; -- OK
SecurityAttributes.nLength := 123; -- ERROR
end Welcome;
Because PSECURITY_ATTRIBUTES is an access (pointer) type and you haven't allocated an instance of it:
type PSECURITY_ATTRIBUTES is access all SECURITY_ATTRIBUTES;
So you have to allocate an instance of it first:
SecurityAttributes : PSECURITY_ATTRIBUTES := new SECURITY_ATTRIBUTES;
(Since it's a pointer type, you don't need "aliased".)
Now you can assign to it:
SecurityAttributes.nLength := 123;
Alternatively, if SecurityAttributes were declared aliased of type SECURITY_ATTRIBUTES, then your original assignment would have worked. Going by the name, I strongly suspect the leading 'P' is intended to indicate the type is a pointer type.
This has not been compiled, I'm going by an on-line source code listing.