Date   

Re: (OT) Image Editing App for Mac?

Jim
 

On Aug 11, 2017, at 9:34 AM, Dave <dave@...> wrote:

Can anyone recommend a light weight Image Creation and Editing App for the Mac?

I’d like to be able to create images with fixed dimensions and background colour and be able to resize images.

Basically I need some text (separate letters/numerals mostly, (“A” to “Z”, “0” to “9”)) of a fixed size. Although I can take screen dumps and resize if necessary.
I’ve been happy with Acorn for those purposes for years. The documentation is great too.

https://flyingmeat.com

Jim Crate


Re: (OT) Image Editing App for Mac?

Sandor Szatmari
 

Try canva.com. They have a reasonable free account for graphics editing online, apparently they have an iOS app too, although I've never tried that.

Sandor

On Aug 11, 2017, at 10:14, Andreas Mayer <andreas@...> wrote:


Am 11.08.2017 um 15:34 schrieb Dave <dave@...>:

Basically I need some text (separate letters/numerals mostly, (“A” to “Z”, “0” to “9”)) of a fixed size.
Um... I might just write code to do that. The 'hardest' thing is probably to get text positioning right.

For general image manipulation I use Pixelmator. I like it but I wouldn't exactly call it light weight.

Or, for vector graphics, there's Affinity Designer. Not light weight either but will work well for what you plan to do.


Andreas


Re: (OT) Image Editing App for Mac?

Andreas Mayer
 

Am 11.08.2017 um 15:34 schrieb Dave <dave@...>:

Basically I need some text (separate letters/numerals mostly, (“A” to “Z”, “0” to “9”)) of a fixed size.
Um... I might just write code to do that. The 'hardest' thing is probably to get text positioning right.

For general image manipulation I use Pixelmator. I like it but I wouldn't exactly call it light weight.

Or, for vector graphics, there's Affinity Designer. Not light weight either but will work well for what you plan to do.


Andreas


Re: (OT) Image Editing App for Mac?

Jim Adams
 

How about Gimp?

On Aug 11, 2017, at 9:34 AM, Dave <dave@...> wrote:

EXTERNAL

Hi,

Can anyone recommend a light weight Image Creation and Editing App for the Mac?

I’d like to be able to create images with fixed dimensions and background colour and be able to resize images.

Basically I need some text (separate letters/numerals mostly, (“A” to “Z”, “0” to “9”)) of a fixed size. Although I can take screen dumps and resize if necessary.

I usually use Photoshop, but I don’t have installed on this machine and I’m travelling, I will install it when I get back, but I need something in the mean time…….

All the Best
Dave




(OT) Image Editing App for Mac?

Dave
 

Hi,

Can anyone recommend a light weight Image Creation and Editing App for the Mac?

I’d like to be able to create images with fixed dimensions and background colour and be able to resize images.

Basically I need some text (separate letters/numerals mostly, (“A” to “Z”, “0” to “9”)) of a fixed size. Although I can take screen dumps and resize if necessary.

I usually use Photoshop, but I don’t have installed on this machine and I’m travelling, I will install it when I get back, but I need something in the mean time…….

All the Best
Dave


CGImage for writing large multi-page tiffs?

Jonathan Taylor
 

Hi all,

At the moment I am saving tiff files in a one-liner using [[myNSImage TIFFRepresentation] writeToFile:atomically:]. I am considering a change to write rather large multi-page tiff files instead of individual files, and am trying to think through the memory implications. The individual images effectively represent single frames of realtime video, which at the moment are written to individual tiff files.

I have two possible concerns over performance, if I switch to writing multi-page tiffs. The first is that that one-liner is going to be doing a lot of work (assembling the tiff data, and writing to disk) in one chunk, instead of spreading it out more evenly over time. The other is that I am going to be accumulating a lot of image data in memory before writing it. That ~might~ be undesirable from a cache point of view, but more importantly I will need to make sure I don’t risk filling up the 32-bit address space. Yes, unfortunately for driver compatibility reasons I am stuck with a 32-bit build here.

I had a quick look around for alternatives to NSImage. It looks as if the CGImage API is more set up for adding images one-by-one to a CGImageDestination, before eventually calling CGImageDestinationFinalize. It’s very possible, though, that behind the scenes the CGImageDestination is just doing the caching in memory itself, before still doing one big write to disk in Finalize. I couldn’t immediately find any documentation about whether there are any such guarantees about performance, nor could I see any way of encouraging it to flush to disk incrementally. Can anyone offer any advice on that?

The other option would be to look for a third-party library. It looks like libtiff would be an option (which supports incremental flushing), but that looks like it’s a lower-level API than I would ideally need. Does anyone have any other recommendations?

Thanks for any suggestions.
Cheers
Jonny


Re: "broken pipe", but not when debugging...

Jonathan Prescott
 

Look at fcntl() (man fcntl). It has an operation parameter of F_SETNOSIGPIPE and F_GETNOSIGPIPE to manage the SIGPIPE signal handling on a file descriptor. Won’t find it in the Xcode documentation, but it is in the BSD man pages.

Jonathan

On Aug 11, 2017, at 12:30 AM, Graham Cox <graham@...> wrote:


On 11 Aug 2017, at 1:42 pm, Graham Cox <graham@...> wrote:

Traditionally the workaround has been to call signal() to install a process-wide no-op handler for SIGPIPE, but on Apple platforms (and others?) you can also set a flag on the file descriptor telling it not to raise the signal. I was going to write that it’s an option to setsockopt, but then I remembered you’re using a pipe not a socket. So I’m not sure what system call you’d use; ioctl maybe?

OK, I’ll look into doing something like this.

Well, this is so far a blind alley.

I can’t find any mention of functions called signal() or ioctl() in the current (Xcode 8) documentation browser. But then, it seems we’ve lost the ability to view man pages. WTF, why are we going backwards with every “update”?

Assume I’m only 5. Where to I find those functions and some sort of documentation for them?

—Graham





Re: "broken pipe", but not when debugging...

Jack Brindle
 

A broken pipe usually means that one end of the connection has been closed for one reason or another. You don’t show the actual
read and write code, but that is most likely where the problem occurs. Be sure and put the data write into a try-catch block in order
to catch the broken pipe (assuming it occurs on a write). This is actually documented, but I’ll have to go find it to say. My notes indicate the
docs to say: This method raises an exception if the file descriptor is closed or is not valid, if the receiver represents an unconnected pipe
or socket endpoint, if no free space is left on the file system, or if any other writing error occurs. The catch block should set pretty much all the
handles to nil, especially the read handle.readabilityHandler. It is pretty easy and useful to set up the readabilityHandler block to get the
data coming from the executable.

This is a two-way street, and it is likely the other end is participating in the broken pipe, if not actually throwing it. If your pipes are not set
up properly and it tries to write to its stdout, you will see this issue.

Also, it might be helpful to debug the son an El Capitan system where we still have a good logging system.

One thing that does look slightly strange is the way the arguments are set up. NSTask really would like for each item to be in a separate
entry (i.e. @[@“ponder”, @“off”, @“noise”, @“1000000”…]. I don’t know if it makes any difference, but is worth trying.

This stuff works pretty well, but there is a lot of opportunity to get broken pipes when one side shuts down for any reason, or simply
closes their side of the connection. Try-catch is definitely your friend here, on both sides of the connection.

- Jack

On Aug 10, 2017, at 4:12 PM, Graham Cox <graham@...> wrote:

Hi,

I’m using NSTask to ‘talk to’ a command line executable that is embedded in my app. I use NSPipe as its stdIn and stdOut channels.
When I run the code under Xcode, it works fine. When I build the app into a standalone executable, it fails with a “broken pipe 13” error message and immediate termination.

Aug 11 09:01:23 The-New-iMac com.apple.xpc.launchd[1] (net.apptree.checkmate.Checkmate.61324[49384]): Service exited due to signal: Broken pipe: 13 sent by Checkmate[49384]

The code seems pretty straightforward, so I can’t see anything tricky. Any ideas what could be causing this?


NSBundle* mainBundle = [NSBundle mainBundle];
NSString* executablePath = [mainBundle pathForAuxiliaryExecutable:@"crafty"];
NSString* resourcePath = [mainBundle resourcePath];

mCrafty = [[NSTask alloc] init];

mCrafty.launchPath = executablePath;
mCrafty.arguments = @[@"ponder off",@"noise 1000000",@"sn 10",@"sd 10"];

NSMutableDictionary* environment = [NSMutableDictionary dictionary];

[environment setObject:resourcePath forKey:@"CRAFTY_BOOK_PATH"];

mCrafty.environment = environment;

[self initStdIn];
[self initStdOut];

NSLog(@"launching crafty");

[mCrafty launch];




- (void) initStdIn
{
NSPipe* inputToCrafty = [NSPipe pipe];

mCrafty.standardInput = inputToCrafty;

NSLog(@"stdIn initialized");
}



- (void) initStdOut
{
NSPipe* craftyOutput = [NSPipe pipe];

craftyOutput.fileHandleForReading.readabilityHandler = ^(NSFileHandle* fileHandle)
{
//[all the stuff that parses the output deleted for clarity]
};

mCrafty.standardOutput = craftyOutput;

NSLog(@"stdOut initialized");
}


Note: For the standalone executable, I don’t see any of the logged (NSLog) messages. I’m not sure why. One difficulty is that the revised Console app makes it a lot harder to figure out what the hell I’m looking at. system.log contains the SIGPIPE error, but none of the log messages. Where did they go?

—Graham






Re: "broken pipe", but not when debugging...

Graham Cox
 

On 11 Aug 2017, at 1:42 pm, Graham Cox <graham@...> wrote:

Traditionally the workaround has been to call signal() to install a process-wide no-op handler for SIGPIPE, but on Apple platforms (and others?) you can also set a flag on the file descriptor telling it not to raise the signal. I was going to write that it’s an option to setsockopt, but then I remembered you’re using a pipe not a socket. So I’m not sure what system call you’d use; ioctl maybe?

OK, I’ll look into doing something like this.

Well, this is so far a blind alley.

I can’t find any mention of functions called signal() or ioctl() in the current (Xcode 8) documentation browser. But then, it seems we’ve lost the ability to view man pages. WTF, why are we going backwards with every “update”?

Assume I’m only 5. Where to I find those functions and some sort of documentation for them?

—Graham


Re: "broken pipe", but not when debugging...

Graham Cox
 

On 11 Aug 2017, at 10:18 am, Jens Alfke <jens@...> wrote:

For some reason lost in ancient Unix history, if you write to a file-descriptor that’s been closed at the other end, a SIGPIPE signal is raised. This will by default kill your process. It’s annoying behavior but it’s long been standardized so it can’t be changed.

This doesn’t happen when run under the debugger because part of the debugger’s job is to catch all signals from your process, and I assume the debugger just ignores SIGPIPE.

OK, makes (some) sense, thanks. I’m wondering why the file descriptor would be ‘closed at the other end’ though - does that mean one of us (the command line tool is not my code but I am compiling from source) is doing something wrong? Or is it normal to close a file descriptor? The communication seems to work otherwise.

Traditionally the workaround has been to call signal() to install a process-wide no-op handler for SIGPIPE, but on Apple platforms (and others?) you can also set a flag on the file descriptor telling it not to raise the signal. I was going to write that it’s an option to setsockopt, but then I remembered you’re using a pipe not a socket. So I’m not sure what system call you’d use; ioctl maybe?

OK, I’ll look into doing something like this.

—Graham


Re: "broken pipe", but not when debugging...

Marco S Hyman
 

On Aug 10, 2017, at 4:12 PM, Graham Cox <graham@...> wrote:


Note: For the standalone executable, I don’t see any of the logged (NSLog) messages. I’m not sure why. One difficulty is that the revised Console app makes it a lot harder to figure out what the hell I’m looking at. system.log contains the SIGPIPE error, but none of the log messages. Where did they go?
Before running your app open the Console app and put the process name of your app in the search bar. The run your app. I believe you'll see your output.

It seems with the new log system is you have to get ready looking for messages before running your app. At least that is the only way I’ve found to see messages. OK when debugging, but useless if trying to find info after the fact.


Re: "broken pipe", but not when debugging...

 


On Aug 10, 2017, at 4:12 PM, Graham Cox <graham@...> wrote:

When I run the code under Xcode, it works fine. When I build the app into a standalone executable, it fails with a “broken pipe 13” error message and immediate termination.

For some reason lost in ancient Unix history, if you write to a file-descriptor that’s been closed at the other end, a SIGPIPE signal is raised. This will by default kill your process. It’s annoying behavior but it’s long been standardized so it can’t be changed.

This doesn’t happen when run under the debugger because part of the debugger’s job is to catch all signals from your process, and I assume the debugger just ignores SIGPIPE.

Traditionally the workaround has been to call signal() to install a process-wide no-op handler for SIGPIPE, but on Apple platforms (and others?) you can also set a flag on the file descriptor telling it not to raise the signal. I was going to write that it’s an option to setsockopt, but then I remembered you’re using a pipe not a socket. So I’m not sure what system call you’d use; ioctl maybe?

—Jens


"broken pipe", but not when debugging...

Graham Cox
 

Hi,

I’m using NSTask to ‘talk to’ a command line executable that is embedded in my app. I use NSPipe as its stdIn and stdOut channels.
When I run the code under Xcode, it works fine. When I build the app into a standalone executable, it fails with a “broken pipe 13” error message and immediate termination.

Aug 11 09:01:23 The-New-iMac com.apple.xpc.launchd[1] (net.apptree.checkmate.Checkmate.61324[49384]): Service exited due to signal: Broken pipe: 13 sent by Checkmate[49384]

The code seems pretty straightforward, so I can’t see anything tricky. Any ideas what could be causing this?


NSBundle* mainBundle = [NSBundle mainBundle];
NSString* executablePath = [mainBundle pathForAuxiliaryExecutable:@"crafty"];
NSString* resourcePath = [mainBundle resourcePath];

mCrafty = [[NSTask alloc] init];

mCrafty.launchPath = executablePath;
mCrafty.arguments = @[@"ponder off",@"noise 1000000",@"sn 10",@"sd 10"];

NSMutableDictionary* environment = [NSMutableDictionary dictionary];

[environment setObject:resourcePath forKey:@"CRAFTY_BOOK_PATH"];

mCrafty.environment = environment;

[self initStdIn];
[self initStdOut];

NSLog(@"launching crafty");

[mCrafty launch];




- (void) initStdIn
{
NSPipe* inputToCrafty = [NSPipe pipe];

mCrafty.standardInput = inputToCrafty;

NSLog(@"stdIn initialized");
}



- (void) initStdOut
{
NSPipe* craftyOutput = [NSPipe pipe];

craftyOutput.fileHandleForReading.readabilityHandler = ^(NSFileHandle* fileHandle)
{
//[all the stuff that parses the output deleted for clarity]
};

mCrafty.standardOutput = craftyOutput;

NSLog(@"stdOut initialized");
}


Note: For the standalone executable, I don’t see any of the logged (NSLog) messages. I’m not sure why. One difficulty is that the revised Console app makes it a lot harder to figure out what the hell I’m looking at. system.log contains the SIGPIPE error, but none of the log messages. Where did they go?

—Graham


Re: How to get full user name prior to 10.12?

Graham Cox
 

On 10 Aug 2017, at 10:28 pm, Shane Stanley <sstanley@...> wrote:

On 10 Aug 2017, at 10:24 pm, Graham Cox <graham@...> wrote:

10.12 added a method to NSProcessInfo, -fullUserName.

How do I get the same info on earlier OS?
The Foundation function NSFullUserName().

Ah, hidden in plain sight! Thanks

G.


Re: How to get full user name prior to 10.12?

Shane Stanley
 

On 10 Aug 2017, at 10:24 pm, Graham Cox <graham@...> wrote:

10.12 added a method to NSProcessInfo, -fullUserName.

How do I get the same info on earlier OS?
The Foundation function NSFullUserName().

--
Shane Stanley <sstanley@...>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


How to get full user name prior to 10.12?

Graham Cox
 

10.12 added a method to NSProcessInfo, -fullUserName.

How do I get the same info on earlier OS?

—Graham


Re: Changing Folder Name in Xcode

Gerriet M. Denkmann
 

Thanks to all who responded!

In my Xcode project, the yellow group “folder” icons in the navigator pane closely resemble the folder structure of my project. And I do not use git or similar.

This is what I did:

1. make sure that all relevant files had in the File inspector → Identity & Type → Location = Relative to Group

2. In Finder I duplicated and renamed the folder

3. Xcode File inspector → Identity & Type → Location clicked the Folder Icon and set the file name to new folder.

4. in Finder removed the old folder.

There were some glitches: I had to remove the. xcconfig things and add them again.
And some file are mentioned in Build Settings (e.g. Info.plist, .entitlement).
But these were minor issues.

Your hint with the folder-icon button in Xcode → File inspector → Identity & Type → Location proved to be extremely helpful.
Thanks to Quincey and Sean for mentioning this.

Kind regards,

Gerriet.


Re: Changing Folder Name in Xcode

Sean McBride
 

On Tue, 8 Aug 2017 17:50:13 +0700, Gerriet M. Denkmann said:

Or close Xcode, rename in Finder, then edit: Some.xcodeproj/
project.pbxproj - but I am afraid of messing with Xcode's private files.
I've done that, and it's worked fine for me.

Can Xcode (Version 8.3.3 (8E3004b)) do this for me? Some sort of refactoring?
If the files are referenced relative it their parent, then I think it's just a matter of re-pointing the folder. Go to Xcode File Inspector > Identity and Type > Location and click that little grey folder icon (that doesn't look like a button at all, of course).

Cheers,

Sean


Re: Changing Folder Name in Xcode

Alex Zavatone
 

On Aug 8, 2017, at 5:50 AM, Gerriet M. Denkmann <g@...> wrote:

I have a project:

Some Folder
Some.xcodeproj
Old and Bad Name
lots of stuff

I would like to change the folder “Old and Bad Name” to “Nice new name”

I could rename this folder in Finder and then reimport “lots of stuff” into Xcode.
But this is very tedious and error prone.

Or close Xcode, rename in Finder, then edit: Some.xcodeproj/project.pbxproj - but I am afraid of messing with Xcode's private files.

Can Xcode (Version 8.3.3 (8E3004b)) do this for me? Some sort of refactoring?

Gerriet.
On the right side of the project in one of the inspectors, there is a means of specifying the path to the item selected and how it is defined. Relative to Group, Relative to Project, Absolute Path, etc…

You can also duplicate your folder, set up the new name and then select the new path to the item from the inspector.

Does that help?

- Alex Zavatone


Re: Changing Folder Name in Xcode

Ben Kennedy
 

On 08 Aug 2017, at 10:16 am, Quincey Morris <quinceymorris@...> wrote:

HOWEVER, if your project is under git source control, doing all this will likely bork your repository pretty well. AFAIK, Xcode 8 isn’t smart enough to change the relative paths inside the repository. In this case, you should probably find some other piece of software to update the names in the repository *first*, then re-open the project in Xcode and fix the groups’ paths.
If you're using Git, this can be mitigated by simply using `git mv` to rename the directory (`git mv oldname newname`).

b

1301 - 1320 of 1475