Xcode editor default to -(void) instead of -(voidPtr)? [closed] - objective-c

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
In Xcode (3.2 on Snow Leopard) when I start to type out a function such as
-(void)myFunctionName {
}
When I first start typing the code hint is
-(voidPtr
What is the difference between void and voidPtr? I assume that voidPtr is a pointer of some kind, what cases call for its use? Do I want to be using voidPtr instead of void?
Can I change a preference in the editor that will default to void and then I can type P and tab complete to voidPtr if I want?
Is there a general way to configure or prioritize code hints so that common hints show up before more obscure code hints?
Can I create code hint shortcuts? Where I type a couple of characters and a command to expand common boilerplate code?
What are some recommended practice tutorials for getting really productive in Xcode editing?
Update: Based on Darren's suggestion it looks like voidPtr comes from
CarbonCore/Threads.h
...
/*
The following ProcPtrs cannot be interchanged with UniversalProcPtrs because
of differences between 680x0 and PowerPC runtime architectures with regard to
the implementation of the Thread Manager.
*/
typedef void * voidPtr;
I am running Xcode on a fresh vanilla install of Snow Leopard. And I have not done anything exotic with my projects. Just starting some very basic tutorials on Xcode and Objective C. Any experienced Objective C folks have useful background info here?

Update: This was a bug in older versions of Xcode. Bug #7256749 has been fixed. I just tried with the newest version of Xcode, and everything is roses.
Historical Info: (for Xcode versions prior to the release of Xcode 4.0)
If you start typing a C-style function declaration:
void SomeFunc(...
Then "void" will appear as the first suggestion. Xcode's code sense applies different rules depending on the surrounding syntax, and when you are creating an Objective-C function declaration, it appears to exclude all of the built in types, including void.
I have filed a bug with Apple (via bugreport.apple.com), and I recommend that you do the same. Apple prioritizes their software fixes (at least partially) based on the number of duplicate reports that they see for a given problem.
Note: Here is the full text of the bug report submitted to Apple:
Summary:
Xcode's code sense provides a list of suggested matches as you type. This list is filtered depending on context. When typing an Objective-C method declaration, the built-in types (void, int, float, etc.) are filtered out. Numeric types such as int and float may be intentionally missing in order to encourage the use of NSInteger or NSNumber, but the void type is still used all the time, and should really appear in the list of suggestions.
Steps to Reproduce:
1. Open Xcode
2. Create a new project with the Cocoa Application template
3. Open the application delegate header file
4. Begin creating a method declaration with a void return type:
    - (vo
5. Press escape to bring up the complete list of suggested completions
Expected Results:
I would expect to see "void" at the top level of the suggestion list, and I would expect it to be highlighted as the most likely choice.
Actual Results:
The list does not even contain "void", and the selected candidate is "voidPtr", which is declared in CarbonCore/Threads.h
Regression:
Unknown, but it definitely happens in the latest build of Xcode (3.2 (1610)) on Mac OS X10.6
Notes:
See discussion on StackOverflow.com (Xcode editor default to -(void) instead of -(voidPtr)?)

voidPtr isn't a standard Objective-C or Cocoa type. XCode is likely presenting voidPtr because it found that symbol somewhere in your project.
You can select "File > Open Quickly" (⌘⇧D) from the menu and type voidPtr to see where that symbol is defined. You can also do the same by holding down the Command key and double-clicking a symbol in your source code.

Related

JSTileMap generating warnings in ios7 SpriteKit template

I am copying JSTileMap and LFCGzipUtility into the project and when I run the application it generates several warnings for both files.
However, when I run the provided sample from github, I don't see any of those warnings.
I would like to know why is there a difference, and in case, what am I doing wrong?
For reference please visit, https://github.com/slycrel/JSTileMap
Clarification, I would like to know if there is anything I should change in the project settings, rather than debug the code that runs just fine and without any warnings on the provided sample at the links above.
if you are running your app in the iOS simulator 64 bit mode then the problem is that the files of JSTileMap are not updated to 64 bit architecture
Apple documents says
Code that relies on the NSInteger and CGFloat types needs to be carefully examined.
Start by building the app for the 64-bit runtime, fixing any warnings that occur as well as searching your code for specific 64-bit issues. For example:
Make sure all function calls have a proper prototype.
Avoid truncating 64-bit values by accidentally assigning them to a 32-bit data type.
Ensure that calculations are performed correctly in the 64-bit version of your app.
Create data structures whose layouts are identical in the 32-bit and 64-bit versions of your app (such as when you write a data file to iCloud).
here is the Apple's transition guide to 64 bit:
https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/Introduction/Introduction.html
if that is not your case the open the file JSTileMap.m, inside press command + f type warning and press enter
and you will find all the warnings that JSTileMap want you to see just comment all warning and thats it
Here i show you all the warnings
#warning these appear to be incorrect for iso maps when used for tile objects! Unsure why the math is different between objects and regular tiles.
#warning This needs to be optimized into tilemap layers like our regular layers above for performance reasons.
#warning the positioning is off here, seems to be bottom-left instead of top-left.
#warning need to write setTileGidAt:
Good Luck!!

Debugging interpreter in VM when changing vm primitives

Context
As a university project we want to change the the pharo vm to use an object-table and see what happens.
We use a pharo-vm clone from github and VMMaker. Building the VM works fine.
To get started we added a primitive that returns an incremented Integer:
InterpreterPrimitives>>primitiveIntegerIncrement
"increments an integer"
self pushInteger: self popInteger + 1 .
and modified StackInterpreter class>>initializePrimitiveTable accordingly
MaxPrimitiveIndex := 576.
"... and so on ..."
(575 primitiveFail)
(576 primitiveIntegerIncrement))
And it works.
Problem
When we make changes to the VM we want to test-run already in the SmalltalkImage so we do not need to compile and see it did not work.
Something like:
StackInterpreter test: '1 inc'
And then I can debug if the primitive is wrong or an error occurs. Of course there needs to be done much more but how can I achieve this?
What we tried
category VMMaker-InterpreterSimulation class StackInterpreterSimulator. Trying the code in the comments
DoIt
^ (StackInterpreterSimulator new openOn: Smalltalk imageName) test
errors:
displayForm := 'Display has not yet been installed' asDisplayText form.
the ByteString does not understand asDisplayText
(CogVMSimulator new openOn: Smalltalk imageName) test
(InterpreterSimulator new openOn: Smalltalk imageName) test
error:
PrimitiveFailed: primitive #basicNew: in Array class failed
I also found this screen cast but it only debugs the VM from outside using gbd: http://vimeo.com/22485382#
Our project is hosted here: http://smalltalkhub.com/#!/~kirstin/PharoObjectTable
Current Status
We started implementing an object table. The lookup of attributes can go throught the object table. Full object table support and no usage of direct pointes is very tricky since pointers are expected everywhere. So we use pointers into the object table to identify when a lookup should go through the OT. We also found all object creation primitives and add new objects to the table.
How long is your project and how many people are you ? To me what you try to do is quite some work. Do you have good knowledge about low level behavior ?
To answer your question, the main problem here is that the cog simulator is not maintained in the pharo vm fork. This is because no one in the pharo crew use the simulator. We only use external debugging from gdb. In fact the pharo folks work mostly on VM plugins, the core of the VM is mainly maintained and developed by Eliot Miranda which works on Squeak. Therefore we report to him when there's a bug in the VM core.
For your project you would have to split it in at least 2 steps:
step 1: make the object table work with the stack VM
step 2: make the JIT work with your object table
Note that for step 2 I would recommend not to change the way an object access its header, therefore having a VW-like object table where you have the fixed size header on the one in the the object table, and the fields of the objects (and maybe header extensions) in the heap.
So use the StackVMSimulator and build the StackVM first. When everything will work (including context), you can think about hacking the JIT. Recently Guillermo Polito ported the Stack VM to the build process (see PharoSVMBuilder instead of PharoVMBuilder), a guy reported problems with this builder but you could hack it a bit to make it work.
Now to make the simulator work on Pharo 2.0 (which is the Pharo version of the generator image you have), you have to open the monticello browser and merge from Eliot's branch the Cog package (repo MCHttpRepository location: 'http: //source. squeak. org/VMMaker'), but not the latest Cog, the one at around the same date as the current VMMaker package of pharo-vm because the latest Cog and VMMaker of Eliot's branch are not stable.
The alternative being to start from Eliot's build image and merge things from the pharo branch. Here are infos about how to build the squeak development image (http://www.mirandabanda.org/cogblog/build-image/).
Then Eliot gave me this script once:
| cos |
cos := CogVMSimulator newWithOptions: #(Cogit SistaStackToRegisterMappingCogit).
cos desiredNumStackPages: 8.
cos openOn: 'my/favourite.image'.
cos openAsMorph; toggleTranscript; halt; run
You don't need the SistaStackToRegisterMappingCogit option. I guess some similar script with the StackVMSimulator should work.
Lastly there are some documentation about the simulator but it is only for the CogSimulator (these documentations expects you already knows how the StackSimulator works, and just give you hints about how to use it with the JIT):
http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/
and in one of the video named "Cog VM (part x)", x being from 1 to 6, Eliot shows how he uses the simulator to disassemble x86, print the stack and inspect the heap.
Another tip, ask your questions on the pharo mailing list (pharo users or pharo dev), because here no one may notice your question (fortunately someone pointed me out your question this time).
And tell on the pharo mailing list if you managed to run the simulator in Pharo 2.0, some people (as me) are very interested in it. I was planning to do it at some point.
Good luck ! Nice project anyway.
The last time I tried to use the simulator is roughly a year ago, and I did not make it work.
However, there are a few patches, which I assume never got integrated that might be of help:
https://code.google.com/p/cog/issues/detail?id=106
https://code.google.com/p/cog/issues/detail?id=107
https://code.google.com/p/cog/issues/detail?id=108
Issue 107 includes a patch for your asDisplayText issue.

Hot Code Swapping in Xcode?

I am doing iOS game development using the cocos2d framework, and I tremendously envy the ability for Eclipse Java programmers to hot swap their code while they are debugging their application (i.e. change out variable values within a method and have the program live update as if you had a REPL without having to recompile).
This seems like something that would be absolutely tremendously helpful when it came to iOS development, where my development environment is (obviously) Xcode and the language I am programming in is Objective C. I have googled around but havent been able to find anything - so I thought I would ask the community.
Does anyone know if there a way to Hot Swap code in Xcode while programming in Objective C?
Thanks in advance
There is a great plugin which allow changing code in live, working APP. It is called InjectionPlugin.
As FAQ says:
How does it work? The Objective-C runtime allows you to load a new version of a class into an application using a bundle even if there is already an implementation linked into the application. Swizzling is used as the bundle is loaded to switch the existing class to use the methods of the new implementation. This can be done repeatedly and works for OSX and iOS applications and on iOS devices.
I made some small video which shows how to install and use this plugin
http://nomtek.com/developers/how-to-install-and-use-injection-plugin-for-xcode/
Hope it helps!
Not possible with the current tools.
Keep in mind that iOS applications are signed -- if you change a single byte you'd have resign the whole thing. One could imagine making it work using runtime's support for dynamically adding and removing methods. But that'd surely require adding some extra stuff to support it on the device, and that's something that malware could easily take advantage of. So it's probably not a feature you'll be likely to see anytime soon.
By the way, Xcode versions 1.x-3.x did have a "Fix and Continue" feature. You could edit as you were debugging, use the Fix and Continue command, and continue running the updated code. I believe it was removed at some point, perhaps due to some combination of: requiring that your project be configured to use "zero link" and perhaps some other things; being less than completely reliable; probably not supporting iOS; the switch to llvm; other changes in Xcode 4. Maybe it'll come back someday -- if you want it back, file a bug -- but again, I think supporting it on iOS would be a challenge.
If you're just talking about changing variable values then you can achieve that surreptitiously via lldb (or, presumably) gdb. Supposing you had:
- (void)uselessMethod
{
NSString *localString = #"I'm some local text";
NSLog(#"%#", localString);
}
And put a breakpoint on the NSLog, at that point you could ask lldb to evaluate a reassignment of localString as a means of performing it. E.g.
po localString = #"Hat"
If you then allow program execution to continue, you should find that the reassignment has stuck. Similarly you can call any method or perform any other sort of assignment.
I've just tested this against Xcode 4.3.2.
You can hot swap a variable value in Xcode by:
expression <variable> = <value>;.
By having a break point in the place where you wanna change the value and doing the command in Xcode console.
Example:
// Messages From Console
(lldb) expression graphFlag = #"X"; // Update variable value
(__NSCFConstantString *) $0 = 0x36f95718 #"X" // Xcode prints the updated value
(lldb) expression graphFlag; // Printing value through expression command
(__NSCFConstantString *) $1 = 0x36f95718 #"X" // Hot Swapped variable value

LGPL grammar file licensing [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Given a LGPL'ed grammar file, is the source generated by a compiler-compiler for the grammar a derivative works? What about if the grammar file was modified before it was given as input to the compiler-compiler? There isn't any linking, at least not in the conventional sense.
If the output is a derivitive work, must I then simply provide the (modified) grammer sources making any best efforts to ensure the grammar will function without dependencies imposed by the program/library using it? Or are there more restrictions which must be resolved?
1) Since the grammar contains the essence of the resulting code, it definitely belongs to "all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities" and is not a part of "the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work". In brief, LGPLv3 applies.
So, you need to convey the "Minimal Corresponding Source" (the one used to build the version in the Combined Work) according to sec.4 d) 0) or GPLv3 sec.6, mark it as modified if it is and possibly include custom tools if required by GPL's definition of "Corresponding Source". (In general, as sec.0 says, LGPLv3 is effectively GPLv3 with a few additional provisions.)
2) It might be a derivative work of the generator used as well if the latter inserts parts of itself into the code (see FSF FAQ#Can I use GPL-covered tools... to compile...?) - check the generator's workings and licensing terms if necessary. If it is, you'll have to satisfy both LGPLv3 and the generator's terms that apply to the results of its work.
The best answer, and which everyone should be giving you is as follows:
Contact a lawyer
Disclaimer: IANAL and if you want something "official" you should talk to one. That said...
A common-sense approach says that yes, the result of compilation of something that is compilable is a derivative work. For instance, the compiled version of an LGPL library is still LGPL - you can't say that you obtained a compiled version of the library and never compiled it yourself and somehow dodge providing the source code that way.
Thus, the LGPL would require you to distribute the (potentially modified) source of the original LGPL work, such that if an individual wanted to further modify the work, they could.

Change build behavior in XCode?

Is there any way to change how XCode compiles my code without completely reprogramming the compiler? Specifically, I want to add a keyword that when used, will invoke a certain behavior for the program. Does anybody know if this is possible?
compiler directives/macros like #define are one way you can go about this. For example objective-c originally started out as compiler directives and unix commands.
Likely what you want to do can be accomplished in a different way. You might want to look into the template system that apple has for interface builder to allow you to add your own objects to IB. Have a look at this question for more.