Re: Embedding resources in Static Cocoa Library
Il giorno 08/ott/2012, alle ore 04:23, Alexander Bokovikov
openwo...@uralweb.ru ha scritto:
As a result, you'll have the address of the embedded information in the eax
register. I.e. you just need to create the function declaration like this one:
(void *) myFunc(void);
and call it. Hope this code is close to correct one, as I never dealt with
Mac OS assembler. And please take it into account, that 5, mentioned in the
code above, means the size of the jmp L2 instruction, which is five in
32-bit assembler, but it will take nine bytes in the 64-bit one. And of
course, I'm talking only about x86/64 assembler. Don't know anything about
PowerPC one.
The only what is left out is how to fill out the .byte with a useful
information. Personally I used a specially written simple utility,
transcoding any binary file into the fixed length lines of .byte hex
codes. You can use decimal or octal codes too. as far as the assembler allows
it.
this is way overkill. You can simply write a simple utility to dump the content
of your resource in a C file:
static char foo[] = {
0x01, 0x02, 0x03,
...
};
You don't need to use assembly nor to create bogus functions to get the address
of foo.
--
Simone Tellini
http://tellini.info
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Hello, all! This a follow-up to a thread started last July. I looked into a lot of things, tested some crazy ideas (that went wrong) and came to my final decision for my project. I consider it very important to let people know what I decided. Maybe I can help someone. And, for sure, you guys can warn me if I'm making the wrong decision. I can say, for sure, that sharing the SQLite database is a bad idea if you have a busy and slow network. The Distributed Objects idea is not so bad, but gives a lot of headaches: the implementation of your business-logic ends up being composed of 90% error handling code. I also dismissed the real-time updates idea. The user will have to refresh the view manually. It saves a lot of effort and users will not get confused by table views changing unexpectedly, for example. So, for the back-end (server side), I'll be using WebObjects to develop a RESTful web service. I chose WebObjects because it's proven, it works very well (Apple uses it on their app stores and iTunes) and it uses a language that is kind of familiar to me (being used to PHP and a couple of C variants). Also, the framework's design patterns are very similar to Cocoa. The development tools are good enough and try to mimic the old tools that Apple provided. It can be deployed on Mac OS X, Linux and others, using standard Java application servers. The WO community seems to be very strong, united and helpful (just check how busy the webobjects-dev list is today). Another reason why I chose this over TouchDB or protocols like SPDY and BLiP, is that I can use a RESTful service with anything. In the future, I could develop clients for different platforms. And WebObjects helps a lot when creating HTML-based interfaces. I looked into Ruby on Rails as an option, but since the Ruby language is very different from everything I know, I chose not to go that route. For the front-end, I'll develop a Cocoa client using ActiveResourceKit (https://github.com/royratcliffe/ActiveResourceKit). From what I've seen, it's the most straight forward to use, and the most feature-complete framework for consuming RESTful web services. I also looked into AFIncrementalStore and RESTKit. Kudos to Steve Steinitz, Jens Alfke, Chris Hanson and Alexander Spohr for the tips. Cheers, Flavio On 18/07/2012, at 16:00, Flavio Donadio wrote: Steve, I agree with Apple, SQLite, you and every other sensible developer out there: I won't try this! :) Cheers, Flavio On 18/07/2012, at 04:49, Steve Steinitz wrote: Hi Flavio, While Apple, SQLite, myself and any sensible software developer advise against it, Core Data can run multi-user by placing the database on a server which supports AFP (e.g. a fast Synology NAS over gigabit ethernet). SQLite has limited optimistic locking support, but the record locking will only work over AFP. As mentioned elsewhere, you still have the (big) problem of keeping the cached objects of each Mac up to date. We do it by getting fresh data from the database, then saving, every minute (plus or minus random seconds) during idle time. The refresh code is complicated, ugly and big -- with bad smells abounding. To make it work at all in Leopard and beyond (when Apple finally put their foot down on this abomination) you need to set a special Apple SQL pragma when creating your persistent store. Our line of code looks like this: [pragmaOptions setObject: [NSNull null] forKey: @lock_proxy_file]; A retailer has been doing this for their Point of Sale (and back-office) on seven Macs for six years. We lost a little data a couple times in the early days and we occasionally get a glitch under heavy Saturday load, but we've tamed the beast and now it works surprisingly well -- and fast. Be warned that there are, as Ben Trumbull once colorfully observed, sharp edges. Cheers, Steve ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Mon, Oct 8, 2012, at 08:40 AM, Flavio Donadio wrote: Hello, all! This a follow-up to a thread started last July. I looked into a lot of things, tested some crazy ideas (that went wrong) and came to my final decision for my project. I consider it very important to let people know what I decided. Maybe I can help someone. And, for sure, you guys can warn me if I'm making the wrong decision. I can say, for sure, that sharing the SQLite database is a bad idea if you have a busy and slow network. The Distributed Objects idea is not so bad, but gives a lot of headaches: the implementation of your business-logic ends up being composed of 90% error handling code. I also dismissed the real-time updates idea. The user will have to refresh the view manually. It saves a lot of effort and users will not get confused by table views changing unexpectedly, for example. I agree with all of your decisions. So, for the back-end (server side), I'll be using WebObjects to develop a RESTful web service. I chose WebObjects because it's proven, it works very well (Apple uses it on their app stores and iTunes) and it uses a language that is kind of familiar to me (being used to PHP and a couple of C variants). Also, the framework's design patterns are very similar to Cocoa. The development tools are good enough and try to mimic the old tools that Apple provided. It can be deployed on Mac OS X, Linux and others, using standard Java application servers. The WO community seems to be very strong, united and helpful (just check how busy the webobjects-dev list is today). We still run WO 4.5 to power our own store, but we go through some major hoops to do so. Personally, I'd be inclined to choose a more stable and up-to-date technology, but I'm not a server-side programmer. For the front-end, I'll develop a Cocoa client using ActiveResourceKit (https://github.com/royratcliffe/ActiveResourceKit). From what I've seen, it's the most straight forward to use, and the most feature-complete framework for consuming RESTful web services. Have you heard of NSIncrementalStore? If you can target Lion and iOS 5, you can continue to use Core Data on the client while communicating with whatever backend and over whatever protocol you choose. Good luck on your project. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Kyle, I like your points and I considered them. It's been 3 months of hair-pulling and I still have some uncertainty about my choices. But I think I made the best decisions, and here's why... We still run WO 4.5 to power our own store, but we go through some major hoops to do so. Personally, I'd be inclined to choose a more stable and up-to-date technology, but I'm not a server-side programmer. WebObjects, in reality, is just a framework. A huge one, to say the least. Users swear by it and think it's still better than Rails, even though it's a decade older! It's very stable too. The true technology behind WO is Java EE. It's a mature and stable platform and has broad adoption. I am sure it's up-to-date (whatever that means, in this case :-) ) The community has been doing a great work to keep it easy to develop WO/EOF apps with Eclipse, since Apple discontinued the official development tools. They also try to improve, fix bugs and work around deprecated Java API's. I've heard (but can't confirm) that Apple uses these same tools (Eclipse, WOLips and the WOnder frameworks) for their projects. So, I think it's a good decision. For the front-end, I'll develop a Cocoa client using ActiveResourceKit (https://github.com/royratcliffe/ActiveResourceKit). From what I've seen, it's the most straight forward to use, and the most feature-complete framework for consuming RESTful web services. Have you heard of NSIncrementalStore? If you can target Lion and iOS 5, you can continue to use Core Data on the client while communicating with whatever backend and over whatever protocol you choose. ActiveResourceKit is based on NSIncrementalStore. It can consume any RESTful web service with very little code, just like any other Core Data store. It's available for Mac OS X and iOS. Check it out. It looks and feels awesome -- although I still didn't spend much time with it... Cheers, Flavio ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Thank you Flavio. Out of curiosity, did you encounter pessimistic vs. optimistic locking performance/data reliability issue in having many clients writing to potentially the same places at once? If so, how did each of the candidate solutions answer the problem that this poses? The problem being if there are multiple users potentially writing to the same place at once, locking records during each write is too slow, but if you don't do this, you end up with the potential of two (or more) people writing to a record at once. An example of this in real life is if both of us try to book a ticket for the last seat on a plane at the same time. We ran into this while modernizing US Food's internal system of everything from COBOL to something else. I'd expect this issue to be of core importance to any multi user or multi homed database. Just curious. Thanks. On Oct 8, 2012, at 11:40 AM, Flavio Donadio wrote: Hello, all! This a follow-up to a thread started last July. I looked into a lot of things, tested some crazy ideas (that went wrong) and came to my final decision for my project. I consider it very important to let people know what I decided. Maybe I can help someone. And, for sure, you guys can warn me if I'm making the wrong decision. I can say, for sure, that sharing the SQLite database is a bad idea if you have a busy and slow network. The Distributed Objects idea is not so bad, but gives a lot of headaches: the implementation of your business-logic ends up being composed of 90% error handling code. I also dismissed the real-time updates idea. The user will have to refresh the view manually. It saves a lot of effort and users will not get confused by table views changing unexpectedly, for example. So, for the back-end (server side), I'll be using WebObjects to develop a RESTful web service. I chose WebObjects because it's proven, it works very well (Apple uses it on their app stores and iTunes) and it uses a language that is kind of familiar to me (being used to PHP and a couple of C variants). Also, the framework's design patterns are very similar to Cocoa. The development tools are good enough and try to mimic the old tools that Apple provided. It can be deployed on Mac OS X, Linux and others, using standard Java application servers. The WO community seems to be very strong, united and helpful (just check how busy the webobjects-dev list is today). Another reason why I chose this over TouchDB or protocols like SPDY and BLiP, is that I can use a RESTful service with anything. In the future, I could develop clients for different platforms. And WebObjects helps a lot when creating HTML-based interfaces. I looked into Ruby on Rails as an option, but since the Ruby language is very different from everything I know, I chose not to go that route. For the front-end, I'll develop a Cocoa client using ActiveResourceKit (https://github.com/royratcliffe/ActiveResourceKit). From what I've seen, it's the most straight forward to use, and the most feature-complete framework for consuming RESTful web services. I also looked into AFIncrementalStore and RESTKit. Kudos to Steve Steinitz, Jens Alfke, Chris Hanson and Alexander Spohr for the tips. Cheers, Flavio On 18/07/2012, at 16:00, Flavio Donadio wrote: Steve, I agree with Apple, SQLite, you and every other sensible developer out there: I won't try this! :) Cheers, Flavio On 18/07/2012, at 04:49, Steve Steinitz wrote: Hi Flavio, While Apple, SQLite, myself and any sensible software developer advise against it, Core Data can run multi-user by placing the database on a server which supports AFP (e.g. a fast Synology NAS over gigabit ethernet). SQLite has limited optimistic locking support, but the record locking will only work over AFP. As mentioned elsewhere, you still have the (big) problem of keeping the cached objects of each Mac up to date. We do it by getting fresh data from the database, then saving, every minute (plus or minus random seconds) during idle time. The refresh code is complicated, ugly and big -- with bad smells abounding. To make it work at all in Leopard and beyond (when Apple finally put their foot down on this abomination) you need to set a special Apple SQL pragma when creating your persistent store. Our line of code looks like this: [pragmaOptions setObject: [NSNull null] forKey: @lock_proxy_file]; A retailer has been doing this for their Point of Sale (and back-office) on seven Macs for six years. We lost a little data a couple times in the early days and we occasionally get a glitch under heavy Saturday load, but we've tamed the beast and now it works surprisingly well -- and fast. Be warned that there are, as Ben Trumbull once colorfully observed, sharp edges. Cheers, Steve ___ Cocoa-dev mailing list
Re: Embedding resources in Static Cocoa Library
On Oct 9, 2012, at 1:00 AM, Simone Tellini wrote:
this is way overkill. You can simply write a simple utility to dump the
content of your resource in a C file:
static char foo[] = {
0x01, 0x02, 0x03,
...
};
You don't need to use assembly nor to create bogus functions to get the
address of foo.
Oops… You haven't caught the idea… Everybody knows how to create a _data_ but
I've described, how to _embed_ data into the _code_ segment. This way can be
used if it's necessary to hide some data against patching.
This code sample is related to software protection area.
Best regards,
Alexander
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Size limit on .icns files containing 1024x1024 version in 10.5?
On 07.10.2012, at 22:04, Andrew Madsen li...@openreelsoftware.com wrote: The problem is that if I include a 1024x1024 icon (icon_512x...@2x.png), the icon does not display on 10.5. Finder doesn't display the icon, and when it is opened in Icon Composer on 10.5, it appears to be blank/empty. If I remove this largest size, the icon displays correctly on 10.5. Interestingly, if I substitute a completely different, simpler 1024x1024 image with a much smaller file size (~300K instead of ~1MB), the icon again works fine on 10.5. Have you tried running oldiconutil in the debugger to see what it actually does? It's a fairly simple tool, so I could guess that e.g. maybe it doesn't detect that the more detailed icon you're using is a PNG file or whatever ... ? Does it actually convert the large variant to JPEG2000? Or maybe your file contains a size I'm not using that just gets carried along and causes the incompatibility? Just guessing here. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On 08/10/2012, at 17:56, Alex Zavatone wrote: Thank you Flavio. Out of curiosity, did you encounter pessimistic vs. optimistic locking performance/data reliability issue in having many clients writing to potentially the same places at once? If so, how did each of the candidate solutions answer the problem that this poses? The problem being if there are multiple users potentially writing to the same place at once, locking records during each write is too slow, but if you don't do this, you end up with the potential of two (or more) people writing to a record at once. An example of this in real life is if both of us try to book a ticket for the last seat on a plane at the same time. I don't think I'll have performance problems. I'll never have more than, say, 20 users at any given time and these race conditions will be rare. The database server can handle this easily, *in my case*. The real problem is in the user interface. The interface will be like in Address Book: the user opens a card/record for viewing, but has to click an Edit button to make changes. If the record is locked, the user will get an alert when he/she clicks the button. I need: 1. A mechanism to avoid users opening records for editing and leaving them open forever (timer?); 2. Some kind of feedback for the users when a record is unlocked, without having to refresh manually. Ideas are very welcome. Cheers, Flavio ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
