ABORT(pid 1):{bsp_set_tagsize} line 136 of "BSP.cpp"
The tag size is not the same on all processors
what that mean?
bsp_begin(bsp_nprocs());
...
bsp_push_reg(matrix,sizeof(int)*sizeMatrix*sizeMatrix);
bsp_push_reg(&answer,sizeof(int));
bsp_sync();
...
for(level=1;level<=sizeMatrix;level++){
...
}
bsp_sync();
bsp_pop_reg(matrix);
bsp_pop_reg(&answer);
bsp_sync();
bsp_end();
in the for there no bsp_sync()
if i put the for at comment it work,
if not it say that error.
someone can explain?
Related
Here in this example I tried to capture two Int values and then capture them together as a struct. This gives a "Thread 1: signal SIGABRT" error.
(NOTE: I know that my example could be fixed by simply not nesting the Captures and handling the pattern matching differently. This is just simplified example code for the sake of this question.)
let intCapture = Regex {
TryCapture(as: Reference(Int.self)) {
OneOrMore(.digit)
} transform: { result in
return Int(result)
}
}
let mainPattern = Regex {
TryCapture(as: Reference(Floor.self)) {
"floor #: "
intCapture
" has "
intCapture
" rooms"
}transform: { ( stringMatch, floorInt, roomInt ) in
return Floor(floorNumber: floorInt, roomCount: roomInt)
}
}
struct Floor {
let floorNumber: Int
let roomCount: Int
}
let testString = "floor #: 34 has 25 rooms"
let floorData = testString.firstMatch(of: mainPattern)
After looking into it, I found that in the mainPattern's 'transform' the 'floorInt' and 'roomInt' are what is causing the problem.
The funny part is that when you look at the 'Quick Help'/Option+click, it shows that they are both type Int! It knows what is there but you are not able to capture it!
Further, when I erase one of them, let's say 'floorInt', it gives this error:
Contextual closure type '(Substring) throws -> Floor?' expects 1 argument, but 2 were used in closure body
So really, even though for SOME reason it does know that there are two captured Int values there, it doesn't let you access them for the sake of the transform.
Not deterred, I was helped out in another question by a very helpful user who pointed me to the Evolution submission where they mentioned a .mapOutput, but sadly it seems this particular feature was never implemented!
Is there no real way to create a new transformed value from nested transformed values like this? Any help would be greatly appreciated.
multi sub infix:<*>( Numeric $i, Block $b ) { &$b($_) for ^($i.Int); }
3 * { .say };
Yields
Useless use of "*" in expression "3 * { .say }" in sink context
How do I get rid of that and make my operator work? I know I could assign it to $ or something else, but I don't want that.
Add this line to the start of your code:
proto sub infix:<*> ( | --> Nil ) {*}
See my answer to Impossible to put a map in sink context for a little on the --> Nil part of this (along with a boatload of irrelevant stuff too) including Larry's 2012 comment:
--> Nil seems like pretty good documentation of a procedure done only for its side-effects
I'm writing a "compiler" of sorts: it reads a description of a game (with rooms, characters, things, etc.) Think of it as a visual version of an Adventure-style game, but with much simpler problems.
When I run my "compiler" I'm getting a syntax error on my input, and I can't figure out why. Here's the relevant section of my yacc input:
character
: char-head general-text character-insides { PopChoices(); }
;
character-insides
: LEFTBRACKET options RIGHTBRACKET
;
char-head
: char-namesWT opt-imgsWT char-desc opt-cond
;
char-desc
: general-text { SetText($1); }
;
char-namesWT
: DOTC ID WORD { AddCharacter($3, $2); expect(EXP_TEXT); }
;
opt-cond
: %empty
| condition
;
condition
: condition-reason condition-main general-text
{ AddCondition($1, $2, $3); }
;
condition-reason
: DOTU { $$ = 'u'; }
| DOTV { $$ = 'v'; }
;
condition-main
: money-conditionWT
| have-conditionWT
| moves-conditionWT
| flag-conditionWT
;
have-conditionWT
: PERCENT_SLASH opt-bang ID
{ $$ = MkCondID($1, $2, $3) ; expect(EXP_TEXT); }
;
opt-bang
: %empty { $$ = TRUE; }
| BANG { $$ = FALSE; }
;
ID: WORD
;
Things in all caps are terminal symbols, things in lower or mixed case are non-terminals. If a non-terminal ends in WT, then it "wants text". That is, it expects that what comes after it may be arbitrary text.
Background: I have written my own token recognizer in C++ because(*) I want the syntax to be able to change the way the lexer's behavior. Two types of tokens should be matched only when the syntax expects them: FILENAME (with slashes and other non-alphameric characters) and TEXT, which means "all the text from here to the end of the line" (but not starting with certain keywords).
The function "expect" tells the lexer when to look for these two symbols. The expectation is reset to EXP_NORMAL after each token is returned.
I have added code to yylex that prints out the tokens as it recognizes them, and it looks to me like the tokenizer is working properly -- returning the tokens I expect.
(*) Also because I want to be able to ask the tokenizer for the column where the error occurred, and get the contents of the line being scanned at the time so I can print out a more useful error message.
Here is the relevant part of the input:
.c Wendy wendy
OK, now you caught me, what do you want to do with me?
.u %/lasso You won't catch me like that.
[
Here is the last part of the debugging output from yylex:
token: 262: DOTC/
token: 289: WORD/Wendy
token: 289: WORD/wendy
token: 292: TEXT/OK, now you caught me, what do you want to do with me?
token: 286: DOTU/
token: 274: PERCENT_SLASH/%/
token: 289: WORD/lasso
token: 292: TEXT/You won't catch me like that.
token: 269: LEFTBRACKET/
here's my error message:
: line 124, columns 3-4: syntax error, unexpected LEFTBRACKET, expecting TEXT
[
To help you understand the equations above, here is the relevant part of the description of the input syntax that I wrote the yacc code from.
// Character:
// .c id charactername,[imagename,[animationname]]
// description-text
// .u condition on the character being usable [optional]
// .v condition on the character being visible [optional]
// [
// (options)
// ]
// Conditions:
// %$[-]n Must [not] have at least n dollars
// %/[-]name Must [not] have named thing
// %t-nnn At/before specified number of moves
// %t+nnn At/after specified number of moves
// %#[-]name named flag must [not] be set
// Condition-char: $, /, t, or #, as described above
//
// Condition:
// % condition-char (identifier/int) ['/' text-if-fail ]
// description-text: Can be either on-line text or multi-line text
// On-line text is the rest of the line
brackets mark optional non-terminals, but a bracket standing alone (represented by LEFTBRACKET and RIGHTBRACKET in the yacc) is an actual token, e.g.
// [
// (options)
// ]
above.
What am I doing wrong?
To debug parsing problems in your grammar, you need to understand the shift/reduce machine that yacc/bison produces (described in the .output file produced with the -v option), and you need to look at the trail of states that the parser goes through to reach the problem you see.
To enable debugging code in the parser (which can print the states and the shift and reduce actions as they occur), you need to compile with -DYYDEBUG or put #define YYDEBUG 1 in the top of your grammar file. The debugging code is controlled by the global variable yydebug -- set to non-zero to turn on the trace and zero to turn it off. I often use the following in main:
#ifdef YYDEBUG
extern int yydebug;
if (char *p = getenv("YYDEBUG"))
yydebug = atoi(p);
#endif
Then you can include -DYYDEBUG in your compiler flags for debug builds and turn on the debugging code by something like setenv YYDEBUG 1 to set the envvar prior to running your program.
I suppose your syntax error message was generated by bison. What is striking is that it claims to have found a LEFTBRACKET when it expects a [. Naively, you might expect it to be satisfied with the LEFTBRACKET it found, but of course bison knows nothing about LEFTBRACKET except its numeric value, which will be some integer larger than 256.
The only reason bison might expect [ is if your grammar includes the terminal '['. But since your scanner seems to return LEFTBRACKET when it sees a [, the parser will never see '['.
I was wondering what this if statement is wrong. I am using swift. What I am trying to do is to perform multiple checks from my textfields, mainly to restrict their text lenght between the ranges declared in the if statement. Here is my code:
if countElements(usernameTextField.text) < 16 &&
countElements(usernameTextField.text) > 4 &&
countElements(passwordTextField.text) > 5 &&
countElements(passwordTextField.text) < 16 {
//Do something
} else {
//Do something else
}
The compiler complains says the following:
"Type 'String!' does not conform to protocol '_CollectionType'"
Do you guys have any idea of why this is showing up?
Thank you in advance for your advice/recommendations/explanations.
Cheers!
text propety in UITextField declared as:
var text: String!
So you should rewrite your code to:
Option 1:
if countElements(usernameTextField.text!) < 16 { ... }
This option is preferable since it will take into account emoji character.
For instance if you add a flag character that counts for 4 places you will be counted as one.
Option 2 (do not use it):
if usernameTextField.text.utf16Count < 16 { ... }
This options counts utf16 symbols so in case of flag emoji you will have visible chars count +3. So do not go this track. I've added this just to show that it should not be used.
I came across a weird issue when testing my opensource project MHTextSearch. At line 169 of MHTextIndex.m:
uint64_t maxLength = [indexedString maximumLengthOfBytesUsingEncoding:encoding];
// some code
for (...) {
[indexedString getBytes:keyPtr
maxLength:maxLength
usedLength:&usedLength
encoding:encoding
options:NSStringEncodingConversionAllowLossy
range:subRange
remainingRange:NULL];
// some more code
}
Nothing, anywhere else, modifies maxLength. On the second iteration, maxLength is equal to 0, no matter what its previous value was. If I set a watchpoint on it, I see it changes in -[NSString getBytes:maxLength:usedLength:encoding:options:range:remainingRange:], at
0x100038d19: movq -0x30(%rbp), %rdx
0x100038d1d: movq %rdx, (%rsi)
0x100038d20: testq %rcx, %rcx << this instruction
The very weird thing about this is that it only happens on the x86_64 architecture, and it can be fixed if I change the code like this
uint64_t maxLength = [indexedString maximumLengthOfBytesUsingEncoding:encoding];
uint64_t strLength = maxLength;
// some code
for (...) {
[indexedString getBytes:keyPtr
maxLength:strLength
usedLength:&usedLength
encoding:encoding
options:NSStringEncodingConversionAllowLossy
range:subRange
remainingRange:NULL];
// some more code
}
With this code, maxLength still gets changed to 0 at the same instruction, but strLength stays consistent, so the effect is removed.
How come?
usedLength has the wrong type. It's declared uint32_t. However, it should be declared NSUInteger, which is 32 bits on 32 bit architectures and 64 bits on 64 bit architectures.