This is the smalltalk code I wrote to deep copy two linkedlist object.But when I do this Small talk interpreter raises an error stating that:Unhandled Exception: Message not Understood: nextlink.
list1 add:2.
list2 :=list1 dcopy.
list1 ==list2.
Kindly tell me what is the problem with my code.
This is VisualWorks. LinkedLists are collections used for internal system use and aren't intended for general use. The items added into LinkedLists must subclass from Link (or implement nextLink and nextLink:). You can't add a SmallInteger into a linked list. You can do this:
LinkedList new
add: (LinkValue value: 5);
add: (LinkValue value: 7)
We don't generally use linked lists in Smalltalk. We normally use OrderedCollection instead. If you really need a linked list, add elements which are subclasses of Link.
Related
Looking for the functionality of the .split_of function as used with a Vec (https://doc.rust-lang.org/std/vec/struct.Vec.html#method.split_off)
Currently I am trying to use the function split_at: (docs: https://docs.rs/ndarray/0.13.1/ndarray/struct.ArrayBase.html#method.split_at)
Usage:
let mut data: Array2<f32> = array![[1.,2.],[3.,4.],[5.,6.],[7.,8.]];
let split = data.split_at(Axis(0),1);
Getting the error:
method not found in `ndarray::ArrayBase<ndarray::data_repr::OwnedRepr<{float}>, ndarray::dimension::dim::Dim<[usize; 2]>>`
What am I missing here?
According to the documentation, these are defined only for ArrayViews and not Arrays.
It's unfortunate that this is stated right above split_at in the documentation, making it easy to miss if you simply click on it from the sidebar of methods.
Methods for read-only array views.
similarly for read-write views.
Initializing a view and splitting it as shown in split_at's documentation should work fine.
I've been wondering how delegated properties ("by"-Keyword) work under-the-hood. I get that by contract the delegate (right side of "by") has to implement a get and setValue(...) method, but how can that be ensured by the compiler and how can those methods be accessed at runtime? My initial thought was that obviously the delegates must me implementing some sort of "SuperDelegate"-Interface, but it appears that is not the case. So the only option left (that I am aware of) would be to use Reflection to access those methods, possibly implemented at a low level inside the language itself. I find that to be somewhat weird, since by my understanding that would be rather inefficient. Also the Reflection API is not even part of the stdlib, which makes it even weirder.
I am assuming that the latter is already (part of) the answer. So let me furthermore ask you the following: Why is there no SuperDelegate-Interface that declare the getter and setter methods that we are forced to use anyway? Wouldn't that be much cleaner?
The following is not essential to the question
The described Interface(s) are even already defined in ReadOnlyProperty and ReadWriteProperty. To decide which one to use could then be made dependable on whether we have a val/var. Or even omit that since calling the setValue Method on val's is being prevented by the compiler and only use the ReadWriteProperty-Interface as the SuperDelegate.
Arguably when requiring a delegate to implement a certain interface the construct would be less flexible. Though that would be assuming that the Class used as a Delegate is possibly unaware of being used as such, which I find to be unlikely given the specific requirements for the necessary methods. And if you still insist, here's a crazy thought: Why not even go as far as to make that class implement the required interface via Extension (I'm aware that's not possible as of now, but heck, why not? Probably there's a good 'why not', please let me know as a side-note).
The delegates convention (getValue + setValue) is implemented at the compiler side and basically none of its resolution logic is executed at runtime: the calls to the corresponding methods of a delegate object are placed directly in the generated bytecode.
Let's take a look at the bytecode generated for a class with a delegated property (you can do that with the bytecode viewing tool built into IntelliJ IDEA):
class C {
val x by lazy { 123 }
}
We can find the following in the generated bytecode:
This is the field of the class C that stores the reference to the delegate object:
// access flags 0x12
private final Lkotlin/Lazy; x$delegate
This is the part of the constructor (<init>) that initialized the delegate field, passing the function to the Lazy constructor:
ALOAD 0
GETSTATIC C$x$2.INSTANCE : LC$x$2;
CHECKCAST kotlin/jvm/functions/Function0
INVOKESTATIC kotlin/LazyKt.lazy (Lkotlin/jvm/functions/Function0;)Lkotlin/Lazy;
PUTFIELD C.x$delegate : Lkotlin/Lazy;
And this is the code of getX():
L0
ALOAD 0
GETFIELD C.x$delegate : Lkotlin/Lazy;
ASTORE 1
ALOAD 0
ASTORE 2
GETSTATIC C.$$delegatedProperties : [Lkotlin/reflect/KProperty;
ICONST_0
AALOAD
ASTORE 3
L1
ALOAD 1
INVOKEINTERFACE kotlin/Lazy.getValue ()Ljava/lang/Object;
L2
CHECKCAST java/lang/Number
INVOKEVIRTUAL java/lang/Number.intValue ()I
IRETURN
You can see the call to the getValue method of Lazy that is placed directly in the bytecode. In fact, the compiler resolves the method with the correct signature for the delegate convention and generates the getter that calls that method.
This convention is not the only one implemented at the compiler side: there are also iterator, compareTo, invoke and the other operators that can be overloaded -- all of them are similar, but the code generation logic for them is simpler than that of delegates.
Note, however, that none of them requires an interface to be implemented: the compareTo operator can be defined for a type not implementing Comparable<T>, and iterator() does not require the type to be an implementation of Iterable<T>, they are anyway resolved at compile-time.
While the interfaces approach could be cleaner than the operators convention, it would allow less flexibility: for example, extension functions could not be used because they cannot be compiled into methods overriding those of an interface.
If you look at the generated Kotlin bytecode, you'll see that a private field is created in the class holding the delegate you're using, and the get and set method for the property just call the corresponding method on that delegate field.
As the class of the delegate is known at compile time, no reflection has to happen, just simple method calls.
This happens to me time and again: I define the class and forget that I wanted it funcallable or it is, say, Gtk widget class, thus it's metaclass needs to be stated. Once it is defined, however, SBCL doesn't let me change me the metaclass (even if there is no instance of this class). For example, evaluating
(defclass foo ()
((slot-a)))
and then adding a metaclass and re-evaluating:
(defclass foo ()
((slot-a))
(:metaclass gobject:gobject-class))
results in error:
Cannot CHANGE-CLASS objects into CLASS metaobjects.
[Condition of type SB-PCL::METAOBJECT-INITIALIZATION-VIOLATION]
See also:
The Art of the Metaobject Protocol, CLASS [:initialization]
Unfortunately I don't have a copy of The Art of the Metaobject Protocol to check what it says. For now the only way I could figure out is to restart lisp, which can be quite disruptive.
Since I realise the error soon enough, I don't mind dodging the defined class completely by removing it. Questions:
If I have created instances of the class, is there a way to find them to nullify them and get them GCed?
How to remove the class? Something like fmakunbound for functions.
Unfortunately I don't have a copy of The Art of the Metaobject Protocol to check what it says.
Even though I recommend reading the book, you can find some information online. See for example ENSURE-CLASS-USING-CLASS.
How to remove the class?
You can use (SETF FIND-CLASS):
(setf (find-class 'foo) nil)
Or, you can use the fancy slime inspector. You call slime-inspect-defintion while pointing the name of the class. Then, you'll see the name. When you select it, you inspect the symbol naming your class. Then, you can see something like:
It names the class FOO [remove]
Provided FOO only names a class, you can use the bigger hammer:
(unintern 'foo)
If I have created instances of the class, is there a way to find them to nullify them and get them GCed?
No, only the GC has the global view, and for practical reasons, it doesn't generally keep backward references about who references a particular object (and how)1.
There is no global record of all instances of a class unless you introduce your own (weak) hash-table to store them. But if you have kept a record of all of your instances, you can CHANGE-CLASS them. For example, you define:
(defclass garbage () ())
... any previously held reference in your object will be released and the GC has an opportunity to dispose of objects your instances where referencing. And when another object reference an instance of 'garbage, you can update it. Instead of using 'garbage, you could probably change instances of old classes to your new class (the name is the same, but the class object is different).
Note also that CHANGE-CLASS is a generic function.
1. Implementations might offer heap walkers. See for example Heap walkers in Allegro CL.
The answer
"Calling a non-virtual function will use the function from the same class as the pointer type, regardless of whether the object was actually created as some other derived type. Whereas calling a virtual function will use the function from the original allocated object type, regardless of what kind of pointer you're using."
was the best to me in the question link
What are the differences between overriding virtual functions and hiding non-virtual functions?
However, I still don't see the benefits of making a function virtual. Why not just make it concrete and override the function when necessary?
All the answers in your link are pretty complicated, since they actually answer more questions than actually asked :-)
I try to make it easier (lets hope for the best):
The concept of a virtual function allows you to guarantee that whatever pointer you use (see the example in the link Parent* p2 or Child* cp) on a class with some inheritance involved, it will always call the "youngest" child's implementation in the inheritance chain.
Example: If you have "child -> parent" and "grandchild -> child -> parent" with exact same function f2() definitions and all virtual, you can now assume that "grandchild::f2" is called in all circumstances. If you omitted the "virtual" keyword in your parent, you would have different functions being called, depending on which pointer you use to access the instance.
So. What is this useful for? Imagine you have a template based collection and want to put children inside the collection that is defined as parent-type collection list<Parent*>. If you now call a function on an element you fetch from the list, you can expect the child's function (definition) to be called! If you omit the "virtual" keyword in the f2() definition, the parents function is going to be called, which might be unexpected/undesired in most cases.
Any better? :-)
How can I tell the Closure Compiler not to rename an inner function? E.g., given this code:
function aMeaninglessName() {
function someMeaningfulName() {
}
return someMeaningfulName;
}
...I'm fine with Closure renaming the outer function (I actively want it to, to save space), but I want the function name someMeaningfulName left alone (so that the name shown in call stacks for it is "someMeaningfulName", not "a" or whatever). This despite the fact that the code calling it will be doing so via the reference returned by the factory function, not by the name in the code. E.g., this is purely for debugging support.
Note that I want the function to have that actual name, not be anonymous and assigned to some property using that name, so for instance this is not a duplicate of this other question.
This somewhat obscure use case doesn't seem to be covered by either the externs or exports functionality. (I was kind of hoping there'd be some annotation I could throw at it.) But I'm no Closure Compiler guru, I'm hoping some of you are. Naturally, if there's just no way to do that, that's an acceptable answer.
(The use case is a library that creates functions in response to calls into it. I want to provide a version of the library that's been pre-compressed by Closure with SIMPLE_OPTIMIZATIONS, but if someone is using that copy of the library with their own uncompressed code and single-stepping into the function in a debugger [or other similar operations], I want them to see the meaningful name. I could get around it with eval, or manually edit the compressed result [in fact, the context is sufficiently unique I could throw a sed script at it], but that's awkward and frankly takes us into "not worth bothering" territory, hence looking for a simple, low-maintenance way.)
There is no simple way to do this. You would have to create a custom subclass of the CodingConvention class to indicate that your methods are "local" externs (support for this was added to handle the Prototype library). It is possible that InlineVariables, InlineFunctions, or RemoveUsedVariables will still try to remove the name and would also need to be fixed up.
Another approach is to use the source maps to remap the stack traces to the original source.
read the following section
https://developers.google.com/closure/compiler/docs/api-tutorial3#export
Two options basically, use object['functionName'] = obj.functionName or the better way
use exportSymbol and exportProperty both on the goog object, here is the docs link for that
http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.html
-- edit
ah, i see now, my first answer is not so great for you. The compiler has some interesting flags, the one which might interest you is DEBUG, which you can pass variables into the compiler which will allow you to drop some debugging annotations in via logging or just a string which does nothing since you are using simple mode.
so if you are using closure you can debug against a development version which is just a page built with dependiencies resolved. we also the drop the following in our code
if(DEBUG){
logger.info('pack.age.info.prototype.func');
}