SystemC allows signals (or members etc.) to be traced via the sc_trace function, the result being a VCD file that can be used in other programs. The naming of these signals is rather arbitrary though, with the function accepting any string (that doesn't have to relate to the variable itself) as a name for the signal to be dumped.
The question is: Can I somehow get the mapping from the sc_interface objects to the string that is used as their name via the SystemC API? I'm logging a lot of data in other ways and it'd be nice to be able to connect the values I retrieve to the VCD data in some way and I can't think of a way to do that if I only have the dumped values and a random string identifier.
Not sure if I understand your question accurately but ...
SystemC makes a difference of eg. signal simulation names and c++ instance names.
The simulation name is specified in the constructor parameter list of the object.
Unless you omitt naming the object during construction the name appearing in the vcd-file should be all but arbitary. On the other hand you omitt the name a name will be generated for you by the alternative constructor.
Maybe you could provide some sample code to rule out any confusion.
sc_signal()
: sc_prim_channel( sc_gen_unique_name( "signal" ) ),
m_change_event_p( 0 ), m_cur_val( T() ),
m_delta( ~sc_dt::UINT64_ONE ), m_new_val( T() ), m_output( 0 ),
m_writer( 0 )
{}
explicit sc_signal( const char* name_ )
: sc_prim_channel( name_ ),
m_change_event_p( 0 ), m_cur_val( T() ),
m_delta( ~sc_dt::UINT64_ONE ), m_new_val( T() ), m_output( 0 ),
m_writer( 0 )
{}
You want to use the latter constructor
Related
Now I have an import(a) function, that in short words dofile's header in .framework like this:
import("<Kakao/KARect>") => dofile("/System/Library/Frameworks/Kakao.framework/Headers/KARect.lua")
And in KARect.lua for example I have:
KARect = {}
function KARect:new(_x, _y, _width, _height, _colorBack)
local new = setmetatable({}, {__index = self})
new.id = KAEntities:generateID()
...
return new
end
function KARect:draw()
...
end
After some time I thought about reworking this system and making "headers" work like typical Lua modules with advanced require() so function will do e.g.:
import("<Kakao/KARect>") => package.path = "/System/Library/Frameworks/Kakao.framework/Headers/?.lua"; KARect = require("KARect")
and file will contain:
local KARect = {}
...
return KARect
Because headers should not contain anything but only classes with their names? I'm getting confused when thinking about it, as I never used Obj C :s
I never used Obj C
Then why are you trying to implement its headers in a language, that does not use headers at all?
Header! What is a header?
Header files in C-like languages store more than just a name. They store constants and macro commands, function and class method argument and return types, structure and class fields. In essence, the contents of the header file are forward declarations. They came into existence due to the need to perform the same forward-declarations across many files.
I don't know what additional rules and functions were added to header files in Obj-C, but you can get general understanding of what they do in the following links: 1, 2, 3, 4 with the last one being the most spot-on.
Answer to the question present
Lua is dynamically-typed interpreted language. It does not do compile time type checks and, typically, Lua programs can and should be structured in a way that does not need forward declarations across files. So there is no meaningful way for a programmer to create and for lua bytecode generator and interpreter to use header files.
Lua does not have classes at all. The code you've posted is a syntactic sugar for an assignment of a function with a slightly different signature to a table which imitates class:
KARect.new = function( first_arg_is_self, _x, _y, _width, _height, _colorBack)
local new = setmetatable({}, {__index = first_arg_is_self})
return new
end
There is no declarations here, only generation of an anonymous function and its assignment to a field in a table. Other parts of program do not need to know anything about a particular field, variable or function (which is stored in variable) in advance (unlike C).
So, no declaration means nothing to separate from implementation. You of course can first list fields of the class-table and do dummy assignments to them, but, again, Lua will have no use for those. If you want to give hints to humans, it is probably better to write a dedicated manual or put comments in the implementation.
Lua has situations where forward declarations are needed to reference local functions. But this situation does not arise in object oriented code, as all methods are accessed through reference to the object, and by the time first object is created, the class itself is usually fully constructed.
I wanted to ask if anyone knows of a programming language where there is dynamic typing but the binding between a name and a type is permanent. Static typing guards your code from assigning a wrong value into a variable, but forces you to declare(and know) the type before compilation. Dynamic typing allows you to assign values with a different type to the same variable one after the other. What I was thinking is, it would be nice to have dynamic typing, but once the variable is bound, the first binding also determines the type of the variable.
For example, using python-like syntax, if I write by mistake:
persons = []
....
adam = Person("adam")
persons = adam #(instead of persons += [adam])
Then I want to get an error(either at runtime or during compilation if possible) because name was defined as a list, and cannot accept values of type Person.
Same thing if the type can not be resolved statically:
result = getData()
...
result = 10
Will generate a runtime error iff getData() did not return an integer.
I know you can hack a similar behavior with a wrapper class but it would be nice to have the option by default in the language as I don't see a good legitimate use for this flexibility in dynamic languages(except for inheritance, or overwriting a common default value such as null/None which could be permitted as special cases).
I have two derived type polymorphic arrays (obj1 and obj2) in a subroutine. Based on the use of the subroutine, while the types of the two arrays may differ, both arrays are the same type; eg both type A or both type B. In the sample code below, I'm only showing one subtype of the abstract class (model), while in reality, I want this to work on multiple subtypes. Furthermore, in the production code, model1's elements have been modified before this copy.
program test
use env_kindtypes, only: si, dp
use abs_obj_model, only: model
use obj_linearDivisionModel, only: linearDivisionModel
implicit none
class(model),allocatable :: model1(:), model2(:)
allocate(linearDivisionModel::model1(10))
!want e.g. model2 = model1([1,4,6,2])
![...]
Given obj1, obj2 (type A) (given as model1, model2 of type linearDivisionMode in the example code) and a set of indices, I want to transfer the specified elements from obj1 to obj2, allocating obj2 in the process.
I have tried quite a few approaches to do so, but none seem to work.
First, I've tried direct assignment using a vector subscript; this fails, complaining that direct assignment of an allocatable polymorphic array is not yet supported.
indices = [ 1 , 2 ]
model2 = model1(indices)
result:
model2 = model1(indices)
1
Error: Assignment to an allocatable polymorphic variable at (1) is not yet supported
Second, I tried using sourced allocation. If I try this with array slice notation, it works (but my problem is not expressible solely with ranges like this). If I try to vector index the source array, it compiles, but upon runtime I get errors from running out of memory (this isn't realistic given the system).
allocate(model2,source=model1(indices))
runtime result:
Operating system error: Cannot allocate memory
Memory allocation failed
Error termination. Backtrace:
#0 0x434471 in __obj_lineardivisionmodel_MOD___copy_obj_lineardivisionmodel_Lineardivisionmode
at build/processed_src/obj_linear_model.f90:462
#1 0x436c75 in cg_charge_fit
at build/processed_src/test.f90:37
#2 0x403019 in main
at build/processed_src/test.f90:22
Works, but isn't sufficient for my purposes.
allocate(model2,source=model1(1:2))
Third, I've been able to allocate the polymorphic array in hopes of manually transferring subelements: However, when I try to do so, I get complaints of polymorphic objects and intrinsic assignment, which I come back to at later in this post.
indices = [ 1 , 2 ]
allocate(model2(size(indices)),source=model1(1))
do i=1,size(indices)
model2(i) = model1(indices(i))
enddo
Error: Nonallocatable variable must not be polymorphic in intrinsic assignment at (1) - check that there is a matching specific subroutine for '=' operator.
I have tried using type select statements to remove the polymorphic context, but errors remain.
select type (POBJECT => model1)
TYPE IS (linearDivisionModel)
allocate(linearDivisionModel::model2(size(indices)))
do i=1,size(indices)
model2(i) = POBJECT(indices(i))
enddo
end select
results:
model2(i) = model1(indices(i))
1
Error: Nonallocatable variable must not be polymorphic in intrinsic assignment at (1) - check that there is a matching specific subroutine for '=' operator
As a work around, I hoped to use an intermediate pointer object, and to source allocation from that. Due to the f2008 standard (which is enforced here) I can't assign a pointer to a vector indexed array. Interestingly, if I create a pointer, vector index that pointer, the compiler segfaults, indicating that there make be something weird going on.
To address the compiler complaints about intrinsic assignment, I've considered writing assignment routines; however, this draws a new set of worries: the parent type both of these routines inherit from is abstract, and I cannot seem to specify a generic deferred assignment operator in that class, leading to a complex parent class which requires quite a few private methods to copy as it specifies no private variables. Furthermore, transformation between subclasses A and B is poorly defined. This still seems to be the only remaining way out, and seems complex.
How can I effectively transfer the specified polymorphic subrarrays?
I'm using gfortran version 6.1.1.
With complete F2008 support, this is simply an assignment statement.
Within the constraints of that compiler, you may need to consider nested SELECT TYPE constructs, that eliminate the polymorphic nature of the left and right hand sides of the assignment.
module my_types
implicit none
type, abstract :: model
end type
type, extends(model) :: linearDivisionModel
character :: comp
end type linearDivisionModel
end module my_types
program p
use my_types
implicit none
class(model),allocatable :: model1(:), model2(:)
integer, allocatable :: indicies(:)
! define model1.
block
type(linearDivisionModel), allocatable :: tmp(:)
allocate(tmp(10))
tmp%comp = ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j']
call move_alloc(tmp, model1)
end block
indicies = [1, 2, 4, 6]
! allocate model2.
allocate(model2(size(indicies)), mold=model1)
! define model2
select type (model1)
type is (linearDivisionModel)
select type (model2)
type is (linearDivisionModel)
model2 = model1(indicies)
end select
end select
! display results.
select type (model2)
type is (linearDivisionModel)
print *, model2%comp
end select
end program p
The above appears to work with current gfortran trunk.
Is it possible to create variables to be a specific type in Lua?
E.g. int x = 4
If this is not possible, is there at least some way to have a fake "type" shown before the variable so that anyone reading the code will know what type the variable is supposed to be?
E.g. function addInt(int x=4, int y=5), but x/y could still be any type of variable? I find it much easier to type the variable's type before it rather than putting a comment at above the function to let any readers know what type of variable it is supposed to be.
The sole reason I'm asking isn't to limit the variable to a specific data type, but simply to have the ability to put a data type before the variable, whether it does anything or not, to let the reader know what type of variable that it is supposed to be without getting an error.
You can do this using comments:
local x = 4 -- int
function addInt(x --[[int]],
y --[[int]] )
You can make the syntax a = int(5) from your other comment work using the following:
function int(a) return a end
function string(a) return a end
function dictionary(a) return a end
a = int(5)
b = string "hello, world!"
c = dictionary({foo = "hey"})
Still, this doesn't really offer any benefits over a comment.
The only way I can think of to do this, would be by creating a custom type in C.
Lua Integer type
No. But I understand your goal is to improve understanding when reading and writing functions calls.
Stating the expected data type of parameters adds only a little in terms of giving a specification for the function. Also, some function parameters are polymorphic, accepting a specific value, or a function or table from which to obtain the value for a context in which the function operates. See string.gsub, for example.
When reading a function call, the only thing known at the call site is the name of the variable or field whose value is being invoked as a function (sometimes read as the "name" of the function) and the expressions being passed as actual parameters. It is sometimes helpful to refactor parameter expressions into named local variables to add to the readability.
When writing a function call, the name of the function is key. The names of the formal parameters are also helpful. But still, names (like types) do not comprise much of a specification. The most help comes from embedded structured documentation used in conjunction with an IDE that infers the context of a name and performs content assistance and presentations of available documentation.
luadoc is one such a system of documentation. You can write luadoc for function you declare.
Eclipse Koneki LDT is one such an IDE. Due to the dynamic nature of Lua, it is a difficult problem so LDT is not always as helpful as one would like. (To be clear, LDT does not use luadoc; It evolved its own embedded documentation system.)
Using the class function allows us to determine the class of an object:
> x = 5
> class(x)
[1] "numeric"
I also understand that we can use the is.object command to determine if an object has a class. However some object types are implicit, that is
> is.object(x)
[1] FALSE
Would it be correct to state that all variables in R are objects and is.object is a test for non-implicit classes only?
Also, how do types fit into this. Naively, I thought that the following piece of code would produce an error:
> x = 5
> class(x) = "fake"
> x = X + 1
> x + 1
[1] 6
attr(,"class")
[1] "fake"
But x still has type "double", still everything still works. Can types be thought of as a superclass that all other objects inherit from?
typeof returns the type of internal C representation, and it is not used for method dispatch. So strictly speaking you can not think of types as "superclasses".
There are instead basic classes (numeric, character, list, function etc) which roughly correspond to the names
returned by typeof, but not always (for example type double is of class numeric, special and closure are of class
function, and class data.frame is of type list!).
With S3 and S4 systems you can build non trivial classes using basic classes (but not necessary extending one of those!! example: setClass("foo", list(a="numeric",b="character") does not extend any of the basic classes).
For objects from these basic classes is.object returns FALSE. As its documentation says, this function provides
a very fast way to check if the object is of user build S3 or S4 class (i.e. not one of basic classes).
After casting x as "fake" your object is formally not of "numeric" class:
is(x, "numeric")
#FALSE
but it is interpretable as basic "numeric" object:
is.numeric(x)
#TRUE
And this is why + works here. So, internally, as #Richie already said the default method interprets x as of
numeric basic class.
This conceptual mess is because of S3 informal treatment of classes. Use S4 instead.
correspondence between typeof(.) and basic class(.):
typeof(.) class(.)
NULL "NULL" "NULL"
1 "double" "numeric"
1:1 "integer" "integer"
1i "complex" "complex"
list(1) "list" "list"
data.frame(x=1) "list" "data.frame"
pairlist(pi) "pairlist" "pairlist"
c "special" "function"
lm "closure" "function"
formals(lm)[[1]] "symbol" "name"
formals(lm)[[2]] "symbol" "name"
y~x "language" "formula"
expression((1))[[1]] "language" "("
(y~x)[[1]] "symbol" "name"
expression(x <- pi)[[1]][[1]] "symbol" "name"
A partial answer to the first question is found in Chapter 2 of the R language defninition
R does not provide direct access to
the computer’s memory but rather
provides a number of specialized data
structures we will refer to as
objects. These objects are referred to
through symbols or variables. In R,
however, the symbols are themselves
objects and can be manipulated in the
same way as any other object.
So, yes, all variables are objects.
is.object seems to be more or less equivalent to function(x) !is.null(attr(x, "class")) but I'm willing to be proved wrong on that.
As for the second question, I think this is what happens:
Since x has class "fake", R looks for a method +.fake in the addition but when it doesn't find one, it resorts to the default method. That default method is based upon underlying C code, which uses typeof(x) (or a C equivalent) to determine what should be done. In this case the type of x is "integer".