SuperCollider * marking the constructor method is not expected - syntax

I tried to create a Class and the constructor always gave me a Syntax Error about the *new method then I just copied the Example from the documentation:
MyClass {
// this is a normal constructor method
*new { | arga, argb, argc |
^super.new.init(arga, argb, argc)
}
init { | arga, argb, argc |
// do initiation here
}
}
and still got this:
ERROR: syntax error, unexpected '*', expecting '}'
in interpreted text
line 6 char 5:
*new { | arga, argb, argc |
^
^super.new.init(arga, argb, argc)
-----------------------------------
ERROR: Command line parse failed
-> nil
From my own class i get the same error concerning the constructor. Where am I wrong?

If you check out the Writing Classes helpfile, there's a bit at the top that's easy to miss about where to save your classes.
https://depts.washington.edu/dxscdoc/Help/Guides/WritingClasses.html
NOTE: Class definitions are statically compiled when you launch
SuperCollider or "recompile the library." This means that class
definitions must be saved into a file with the extension .sc, in a
disk location where SuperCollider looks for classes. Saving into the
main class library (SCClassLibrary) is generally not recommended. It's
preferable to use either the user or system extension directories.
Platform.userExtensionDir; // Extensions available only to your user account
Platform.systemExtensionDir; // Extensions available to all users on the machine
It is not possible to enter a class definition into an interpreter
window and execute it.
The the Save As Extension option under the file menu. Then recompile the interpretter and try using your class.

Related

Error while passing jmeter simple configuration in build.gradle.kts

While trying to pass simple configuration in build.gradle.ktl file for running jmeter gradle. plugin (https://github.com/jmeter-gradle-plugin/jmeter-gradle-plugin/wiki/Getting-Started)
I am trying to pass simple configuration and my build.gradle.kts file looks like below
jmeter {
jmTestFiles = [file("src/test/jmeter/test2.jmx")] //if jmx file is not
in the default location
jmSystemPropertiesFiles= [file("src/test/jmeter/jmeter.properties")]
//to add additional system properties
enableExtendedReports = true //produce Graphical and CSV reports
}
I am encountering following error
Script compilation errors:
Line 7: jmTestFiles = [file("src/test/jmeter/test2.jmx")]
^ Type mismatch: inferred type is Array but (Mutable)List! was expected
Line 7: jmTestFiles = [file("src/test/jmeter/test2.jmx")]
^ Unsupported [Collection literals outside of annotations]
Line 8: jmSystemPropertiesFiles=
[file("src/test/jmeter/jmeter.properties")]
^ Type mismatch: inferred type is Array but (Mutable)List! was expected
Line 8: jmSystemPropertiesFiles=
[file("src/test/jmeter/jmeter.properties")]
^ Unsupported [Collection literals outside of annotations]
4 errors
I figured out the syntax had to be adopted to kotlin format below
jmSystemPropertiesFiles = mutableListOf(file("src/test/jmeter/jmeter.properties"))

Where is my GenesisConfig entry for my config storage?

I'm trying to reconstruct the Sudo module's root key behaviour before I extend it. Following the v1 documentation on GenesisConfig, I have a config() storage variable in my decl_storage:
RootKey get(fn rootkey) config(): T::AccountId;
(in the node-template template.rs for now)
Yet, if I look at the macro-expanded output, I have no template item in the GenesisConfig struct, and I cannot put in an entry like the following in the chain_spec's testnet_genesis function
template: Some(TemplateConfig {
rootkey: root_key,
}),
Because I get a complaint about both template and TemplateConfig, even though both are supposed to be constructed by the macro expansion.
Edit: Specifically, if it add the above with a TemplateConfig item in the use runtime::{} list, I am informed:
error[E0432]: unresolved import `runtime::TemplateConfig`
--> node-template/src/chain_spec.rs:4:14
|
4 | SudoConfig, TemplateConfig, IndicesConfig, SystemConfig, WASM_BINARY, Signature
| ^^^^^^^^^^^^^^ no `TemplateConfig` in the root
error[E0560]: struct `node_template_runtime::GenesisConfig` has no field named `template`
--> node-template/src/chain_spec.rs:142:3
|
142 | template: Some(TemplateConfig {
| ^^^^^^^^ `node_template_runtime::GenesisConfig` does not have this field
|
= note: available fields are: `system`, `aura`, `grandpa`, `indices`, `balances`, `sudo`
I also don't see any template items in polkadot.js under storage, whereas I do see sudo's key().
What obvious thing am I missing?
When trying to set up the genesis configuration for a runtime module you need to do the following:
Make sure your runtime module has "configurable storage items". This could be as simple as setting config() in the decl_storage! macro, but could also be a bit more complicated as documented here: `decl_storage! - GenesisConfig.
decl_storage! {
trait Store for Module<T: Trait> as Sudo {
Key get(fn key) config(): T::AccountId;
//--------------^^^^^^^^---------------
}
}
This will generate a GenesisConfig in your module, which will be used in the next step.
Next you need to expose your module specific GenesisConfig struct to the rest of your runtime's genesis configuration by adding the Config/Config<T> item to your construct_runtime! macro. In this example, we use Config<T> because we are configuring a generic T::AccountId:
construct_runtime!(
pub enum Runtime where
Block = Block,
NodeBlock = opaque::Block,
UncheckedExtrinsic = UncheckedExtrinsic
{
//--snip--
TemplateModule: template::{Module, Call, Storage, Event<T>, Config<T>},
//----------------------------------------------------------^^^^^^^^^--
}
}
This will generate an alias to your module specific GenesisConfig object based on the name you configured for your module (name + Config). In this case, the name of the object will be TemplateModuleConfig.
Finally, you need to configure this storage item in the chain_spec.rs file. To do this, make sure to import the TemplateModuleConfig item:
use node_template_runtime::{
AccountId, AuraConfig, BalancesConfig, GenesisConfig, GrandpaConfig,
SudoConfig, IndicesConfig, SystemConfig, WASM_BINARY, Signature,
TemplateModuleConfig,
//--^^^^^^^^^^^^^^^^^^^^
};
And then configure your genesis information:
template: Some(TemplateModuleConfig {
key: root_key,
}),
It sounds like you're missing use TemplateConfig at the beginning of your chain_spec.rs file. Something like this https://github.com/substrate-developer-hub/substrate-node-template/blob/8fea1dc6dd0c5547117d022fd0d1bf49868ee548/src/chain_spec.rs#L4
If this is not your issue please supply the exact error you're getting, and optionally a link to the full code.

Vala error "unknown type name" using enum from camel

I am writing this code in Vala, using Camel
using Camel;
[...]
MimeParser par = new MimeParser();
[...]
par.push_state( MimeParserState.MULTIPART, boundary );
I downloaded the camel-1.2.vapi from github vala-girs (this link), put it in a vapi subdirectory and compiled with
valac --vapidir=vapi --includedir=/usr/include/evolution-data-server/camel --pkg camel-1.2 --pkg posix --target-glib=2.32 -o prog prog.vala -X -lcamel-1.2
Compiling I get this error:
error: unknown type name "CamelMimeParserState"
const gchar* camel_mime_parser_state_to_string (CamelMimeParserState self);
Looking the C output code I see that the CamelMimeParserState type is used several times but it is never defined. It should be a simple enum because the camel-1.2.vapi file says:
[CCode (cheader_filename = "camel/camel.h", cprefix = "CAMEL_MIME_PARSER_STATE_", has_type_id = false)]
public enum MimeParserState {
INITIAL,
PRE_FROM,
FROM,
HEADER,
BODY,
MULTIPART,
MESSAGE,
PART,
END,
EOF,
PRE_FROM_END,
FROM_END,
HEADER_END,
BODY_END,
MULTIPART_END,
MESSAGE_END
}
So why doesn't the C output code simply use an enum as the vapi file says (described by cprefix CAMEL_MIME_PARSER_STATE_)?
Is there an error in the .vapi file?
I found the solution. The vapi file is wrong because the cname field is missing. Changing the vapi file adding this cname="camel_mime_parser_state_t":
[CCode (cheader_filename = "camel/camel.h", cname="camel_mime_parser_state_t", cprefix = "CAMEL_MIME_PARSER_STATE_", has_type_id = false)]
public enum MimeParserState {
INITIAL,
[...]
works correctly.

Appending a byte into a byte array in Java Card

I have a method below to insert a single byte into a byte buffer and during building and cleaning for a Java Card CAP file it throws an error.
Code:
private void appendOutputBuffer(byte msg) {
ArrayLogic.arrayCopyRepack(msg, (short) 0, (short) 0, outputBuffer, (short) outputBuffer.length);
}
Error:
error: line 163: sctest: class java.lang.Byte not found in export file lang.exp.
error: line 163: sctest: method valueOf(byte) of class java.lang.Byte not found in export file lang.exp or the method signature has changed.
error: line 163: sctest: class java.lang.Byte not found in export file lang.exp.
error: line 163: sctest: class java.lang.Byte in return type of method java.lang.Byte.valueOf(byte) not found.
How do I resolve it ?
This is not how arrayCopyRepack works. Read the documentation: http://www.win.tue.nl/pinpasjc/docs/apis/jc222/javacardx/framework/util/ArrayLogic.html#arrayCopyRepack%28java.lang.Object,%20short,%20short,%20java.lang.Object,%20short%29
Its signature is:
public static final short arrayCopyRepack(Object src,
short srcOff,
short srcLen,
Object dest,
short destOff)
but the src argument is meant to be an array - it is an Object just because there is no common ancestor class for all primitive arrays in Java Card. Not everything in Java Card is an Object: byte is a primitive. That causes your troubles.
The first step of Java Card build is a common Java compiler creating a standard .class file. This compiler does not know anything about Java Card and it sees a byte used as an Object, so it uses autoboxing, casting your byte to java.lang.Byte and adding a dependence to java.lang.Byte in your .class file. So far so good. This is just plain Java, so it works.
However, in Java Card libraries there is no java.lang.Byte in java.lang package. That causes the error when creating a .cap file.
Appending a byte to an existing array (and thus creating a new array) is a very bad idea, btw. You should create your buffer long enough and store the effective length (how long is the used part of the buffer):
private static final short BUF_LEN = (short) 256;
byte[] outputBuffer = new byte[BUF_LEN];
...
private void appendOutputBuffer(byte msg) {
if (effectiveLen == BUF_LEN)
ISOException.throwIt(ISO7816.SW_UNKNOWN);
outputBuffer[effectiveLen] = msg;
++effectiveLen;
}
and think about RAM vs EEPROM storing of both outputBuffer and effectiveLen.

CLR IL-significance of square bracket on .locals init

I am trying to generate a dynamic assembly using Reflection & Emit in .NET. I am getting an error, "Common Language Runtime detected an invalid program." I created another program which has the functionality I want using hard-coded types. The functionality I am trying to write will ultimately use dynamic types, but I can use ILDasm to see the IL I need to generate. I am comparing the IL I am generating with the IL which the compiler generates. In the .locals init declaration of one method I see there is an extra item in the compiler-generated code,
compiler-generated:
.locals init ([0] class [System.Core]System.Linq.Expressions.ParameterExpression CS$0$0000,
[1] class [System.Core]System.Linq.Expressions.ParameterExpression[] CS$0$0001)
mine:
.locals init (class [System.Core]System.Linq.Expressions.ParameterExpression V_0,
class [System.Core]System.Linq.Expressions.ParameterExpression[] V_1)
I don't understand the significance of the "[0]" and "[1]" in the compiler-generated code. Can anyone tell me what it means?
As a more general question, I can follow most ILDasm output without too much trouble. But every so often I run across a problematic expression. For instance, in this line from ILDasm
callvirt instance class [EntityFramework]System.Data.Entity.ModelConfiguration.EntityTypeConfiguration`1<!!0> [EntityFramework]System.Data.Entity.DbModelBuilder::Entity<class DynamicEdmxTrial.HardFooAsset>()
the "!!0" probably refers to the generic type of the Entity<>, but I don't know for sure, and I wonder if there is a key to ILDasm output that would explain its more obscure output to me.
The specification is freely available here. It takes a little getting used to, but most details are easily found once you figure out the structure.
!! is listed in II.7.1 Types:
Type ::= | Description | Clause
‘!’ Int32 | Generic parameter in a type definition, | §II.9.1
| accessed by index from 0 |
| ‘!!’ Int32 | Generic parameter in a method | §II.9.2
| definition, accessed by index from 0 |
...
In other words, inside a method that C# would call f<T, U>(), !!0 would be T, and !!1 would be U.
However, the [0] is a good question. The spec does not seem to address it. The .locals directive is described in II.15.4.1.3 The .locals directive, which lists the syntax as
MethodBodyItem ::= ...
| .locals [ init ] ‘(’ LocalsSignature ‘)’
LocalsSignature ::= Local [ ‘,’ Local ]*
Local ::= Type [ Id ]
There is nothing that seems to allow [0] there unless it is part of a Type, and Type does not allow anything starting with [ either. My guess is that this is an undocumented peculiarity specific to Microsoft's implementation, intended to help the human reader see that location 0 is local variable CS$0$0000, for when the generated instructions access local variables by index.
Experimenting with ILAsm shows that this is exactly what it means. Taking a simple C# program:
static class Program {
static void Main() {
int i = 0, j = 1;
}
}
and compiling and then disassembling it (csc test.cs && ildasm /text test.exe >test.il) shows:
....
.locals init (int32 V_0,
int32 V_1)
IL_0000: nop
IL_0001: ldc.i4.0
IL_0002: stloc.0
IL_0003: ldc.i4.1
IL_0004: stloc.1
IL_0005: ret
....
Modifying the .locals to
.locals init ([0] int32 V_0, [0] int32 V_1)
gives a useful warning message:
test.il(41) : warning : Local var slot 0 is in use
And indeed, declaring variables of different types, then reordering them using [2], [1], [0], assembling and immediately disassembling the result, shows that the variables got reordered.

Resources