Manipulating Table View Cells

[David Grant]

I’d like to know how to edit table view cells as it is done in health kit, when 
some one adds a data point.

I finally got a view within my app just right in terms of making it looks that 
way, and I’m hoping someone can point me in the right direction.

I’m not looking for anything too complicated, anything similar to health kit 
data points will work for my needs.

Thanks,

David
___

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: Generate a _CFURLAliasData entry for Finder toolbar

[Kyle Sluder]

On Fri, May 15, 2015, at 02:37 PM, Gary Ash wrote:
> I’m trying to programmatically add a link to an app to Finder’s toolbar.

Programmatic customization of the Finder toolbar is not supported.

If you are not in the MAS, you can use LSSharedFileList and
Authorization Services APIs to place items in the Favorites list.

> I’ve found that dragging  an app onto the toolbar works like a charm and
> adds a dictionary entry to NSToolbar Configuration Browser->TB Item
> Plists in the format:

Reaching into another app's Preferences usually doesn't work (unless the
other app is expecting it), and is a sandbox violation.

--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

Generate a _CFURLAliasData entry for Finder toolbar

[Gary Ash]

I’m trying to programmatically add a link to an app to Finder’s toolbar.
I’ve found that dragging  an app onto the toolbar works like a charm and adds a 
dictionary entry to NSToolbar Configuration Browser->TB Item Plists in the 
format:

_CFURLStringType Number 15
_CFURLString String 
file:///Applications/FinderTools.app/Contents/Resources/fix-finder.app
_CFURLAliasData  Data   < 01b2 00010c4d 6163696e 746f7368 20484400 
   d0f7 f515482b 0091 31b90e66 69782d66 
696e6465 722e6170 7000      
      0091 31bdd17b 
bfda    0920    
00095265 736f7572 63657300 0018 d0f8 3b65 00110008 d17b 
f81a 00010010 009131b9 009131b2 009131b1 008a 0002004f 4d616369 
6e746f73 68204844 3a417070 6c696361 74696f6e 733a0046 696e6465 72546f6f 
6c732e61 70703a00 436f6e74 656e7473 3a005265 736f7572 6365733a 00666978 
2d66696e 6465722e 61707000 000e001e 000e0066 00690078 002d0066 0069006e 
00640065 0072002e 00610070 007f 001a000c 004d0061 00630069 006e0074 
006f0073 00680020 00480044 0012003e 4170706c 69636174 696f6e73 2f46696e 
64657254 6f6f6c73 2e617070 2f436f6e 74656e74 732f5265 736f7572 6365732f 
6669782d 66696e64 65722e61 70700013 00012f00 >

I’m having trouble decoding an replicating the _CFURLAliasData entry. If figure 
it has to be the output from bookmarkDataWithOptions but I haven’t hit on the 
right combination of options and I wondered if anyone has an insight to offer. 
Looking at in with hex editor seems to show an HPFS path but it’s not as simple 
as specifying NSURLBookmarkCreationSuitableForBookmarkFile.

Thanks for any help
Gary
___

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: Optionals? A better option!

[Jens Alfke]

> On May 15, 2015, at 10:12 AM, Scott Ribe  wrote:
> 
> As in the olden days of OS 9 & before, when you could freely read & write 
> through location 0, usually leading to great hilarity…

Especially since the 68k CPU interrupt vectors were stored in low memory a few 
bytes from 0, so a memcpy or struct write to NULL would cause an immediate 
total system freeze.

Anyone who was developing for the Mac in those dark days remembers the 
indispensable system extension EvenBetterBusError (son of Mr. Bus Error), which 
would every few milliseconds (a) write an invalid address to location 0, and 
(b) trigger an exception if that value had been changed since it last wrote it. 
It wouldn’t catch dereferencing a null pointer, but it would catch 
dereferencing a null _handle_, and those were at least as common back then.

See: 
http://www.mactech.com/articles/mactech/Vol.13/13.05/CodeMechanic/index.html 


—Jens
___

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: Optionals? A better option!

[Scott Ribe]

On May 15, 2015, at 11:06 AM, Kyle Sluder  wrote:
> 
> It's not valid to dereference a null pointer, but what happens when you
> do is undefined.

As in the olden days of OS 9 & before, when you could freely read & write 
through location 0, usually leading to great hilarity…

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice






___

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: Optionals? A better option!

[Kyle Sluder]

On Fri, May 15, 2015, at 11:31 AM, Jens Alfke wrote:
> Yes, but when you evaluate (cdr nil) doesn’t the interpreter trigger an
> exception? (Sorry, it’s been decades since I used LISP.) Similarly, in
> Smalltalk-80 ‘null’ is a real object, a singleton of class
> UndefinedObject, but trying to message it is going to raise a
> message-not-handled exception. The difference from a nil pointer is
> mostly that you get a language-level rather than an OS-level exception.

Just as a point of esoterica, nothing about the C spec requires the null
pointer to map to a hardware-level trap. The only requirement is that
there exist a value called the null pointer in every pointer type, that
all null pointers compare equal to each other, and that they do not
compare equal to any non-null pointers.

It's not valid to dereference a null pointer, but what happens when you
do is undefined.

The assumption that dereferencing a null pointer would always lead to a
hardware fault led to a pretty serious vulnerability in the Linux
kernel: http://lwn.net/Articles/342330/

Here's some more elaboration:
https://software.intel.com/en-us/blogs/2015/04/20/null-pointer-dereferencing-causes-undefined-behavior

And all of this is why Swift and every other modern programming
languages goes the route of Optionals.

--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: Optionals? A better option!

[Jens Alfke]

> On May 15, 2015, at 4:34 AM, has  wrote:
> 
> Lisp has a `nil` object. That's not the same thing as a nil pointer. The 
> first is an actual Thing; the second is a promise to give you a thing that 
> instead drops you down a hole when you actually ask for it.

Yes, but when you evaluate (cdr nil) doesn’t the interpreter trigger an 
exception? (Sorry, it’s been decades since I used LISP.) Similarly, in 
Smalltalk-80 ‘null’ is a real object, a singleton of class UndefinedObject, but 
trying to message it is going to raise a message-not-handled exception. The 
difference from a nil pointer is mostly that you get a language-level rather 
than an OS-level exception.

> I *really* wish Swift designers had copied FP's elegant type declaration and 
> pattern matching syntax, instead of godawful C++ hideousness. It's so much 
> cleaner it isn't funny.

I said similar things when Java first came out — “it’s a whole new language! 
Why did they have to copy the awful C syntax?” — but from a pragmatic 
standpoint I was wrong. A big part of the reason Java took off was that it 
looked familiar to C and C++ programmers. A language with an awesome syntax is 
still a failure if people won’t adopt it. (Of course you can take that too far 
end end up with miserable pidgins like PHP…) For better or worse, all* of the 
languages I know of in the new Modern Systems Programming category (Go, Rust, 
Swift, …) have a surface-level similarity to C.

—Jens

* Oops, Nim doesn't. But Nim also doesn’t seem to have as much traction, which 
bolsters my point.
___

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: Optionals? A better option!

[has]

Jens Alfke wrote:

> Which is to say that, if you really want to engage in productive 
debate or provide alternatives, you should spend some time learning the 
theory behind languages and also looking at non-C-like languages, 
especially functional ones.


This. C doesn't even have a typesystem: just a handful of compiler 
directives for allocating memory on the stack. If your only experience 
is in C and its descendents, you're simply not qualified to discuss type 
system design. Go learn a language like Haskell or ML that has a real 
type system; it'll open your eyes. Type systems are for expressing your 
exact requirements in terms of set theory, not checking homework of the 
terminally sloppy and lazy.



> Optionals come out of a long line of thinking in functional 
programming languages. The broader idea is that if a value can have 
multiple mutually exclusive states (in this case “has a value” vs “has 
no value”) then those states should be tagged and should require 
explicit action to select between. That’s basically what Swift enums are 
(and the same concept is found in a lot of other languages like Haskell, 
Erlang, Scala, Rust…)


Indeed. The common term in FP is "sum types". (Also known as" variant 
types" or "tagged unions", though I dislike that last term as it 
emphasizes implementation rather than purpose - another easy engineer 
trap.) Here's a quick read:


 
https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/sum-types

Basically, just think of `FooType?` as a syntactic shorthand for writing 
`FooType | NoneType`, i.e. the sum of FooType and NoneType. [1]


Similarly, `foo = foo_or_none as FooType!` is just shorthand for 
concisely expressing a common use-case where your code can't reasonably 
continue unless the value given is an instance of FooType:


case foo_or_none of
SomeType (foo) -> [process the foo value as normal]
NoneType -> [throw a standard exception]

Frankly, if you want to grouse about something, grouse about Swift's 
love of syntactic special forms, which makes the language look even more 
semantically complex and disjointed than it actually is. Having cut my 
coder's teeth on AppleScript, I know this special hell only too well 
already.



> There’s a school of thought that null pointers are harmful; optionals 
are a reaction to that. I just looked up the source — Tony Hoare gave a 
presentation where he formally apologized for inventing null pointers in 
1965 as part of ALGOL W: [...] It’s a great quote, but I don’t think 
that was the first appearance of null. LISP dates back to the late ‘50s 
and has always had nil references (right?)


Lisp has a `nil` object. That's not the same thing as a nil pointer. The 
first is an actual Thing; the second is a promise to give you a thing 
that instead drops you down a hole when you actually ask for it.



HTH

has

[1] Pseudocode, obviously. I *really* wish Swift designers had copied 
FP's elegant type declaration and pattern matching syntax, instead of 
godawful C++ hideousness. It's so much cleaner it isn't funny.

___

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