Re: [MacRuby-devel] Document based application template
Hi all, I know, it is a lame advice but maybe you should upgrade Xcode / MacRuby. Then you can create a Document based application via the wizard which works like charm for me. If everything is not working, drop me a line and i can send you the generated skeleton from the wizard. On Dec 22, 2011, at 8:46 AM, Min Soo Kim wrote: > Hi Andy Stechishin, > > I am have the same problem as you. > It seems that no one is answering to your question. > Have you find a what the problems was? > > Thank you in advance > > Min Soo Kim > > > On Jul 23, 2011, at 12:46 PM, Andy Stechishin wrote: > >> I am trying to make a Document based MacRuby application. I create the >> new project in Xcode4 (4.0.2) and immediately select build and run. >> The application starts but there is no "Untitled" window and the >> File->New and File->Open menu options are greyed out. Following the >> same sequence of actions except choosing an Objective-C based >> application, the "Untitled" Window appears and the menu options are >> active. I have compared the project contents, the xib files (including >> File Owners and First Responders) and linked frameworks and can find >> no difference that would explain the different operation. It would >> seem that there is some problem with NSDocumentController in the >> MacRuby version. It is either not there or has been added properly to >> the responder chain. >> >> Am I missing something? Or is this a defect? Has anyone else >> encountered this and found a work around? >> >> Andy Stechishin >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel Maik Kempe Br∑αkíηg £ímíτs | impossible = POSSIBLE -- Br∑αkíηg £ímíτs [email protected] breaking-limits.com ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] A Future for MacRuby
Hey all, I think we need to understand that this thread has been conflating two different issues: 1. Apple support for MacRuby, and 2. the future roadmap for MacRuby. As for #1: I would respectfully suggest that if you feel you need some sort of official "blessing" from Apple in order to continue working with/on MacRuby, then your time may be better spent elsewhere. Apple is not a particularly developer-centric company, and to be honest I wouldn't put much weight on any word from Cupertino anyway. Am I the only one who remembers Dylan? (Just in case: http://en.wikipedia.org/wiki/Dylan_(programming_language) ) That said, people are using C# and other .Net languages to develop for the Mac and iPhone with no official blessing or Xcode integration. People have used Scheme/Nu for Cocoa development, and there are even alternative IDEs for working with Obj-C now. Then there's Lua. Has everyone seen Codea ( http://twolivesleft.com/Codea/)? If they can do it without Apple's help, there's no reason MacRuby can't. As for #2: I would love to have a discussion about MacRuby's future. In my mind, there's not much point in trying to make MacRuby a "better" Ruby 1.9/2.0. There's already a three-horse race between MRI, Rubinius, and JRuby for the title of "best" Ruby. Obviously, we will always strive for as much feature parity as possible, but the best way to know what features to focus on is to write code. Need Fibers? Tell us. Need encoding support? Well, it should already be there...but if you feel something is missing/lacking, let us know. (BTW, I've been keeping an eye on the design of keyword-args in 2.0, and so far it would not be impossible to support that feature in MacRuby.) I think it is fairly clear that MacRuby's strength is going to be in native apps, so what can we do to make MacRuby stand out from every other way to write native apps? HotCocoa is definitely an interesting direction, but there are other approaches that can be explored as well (such as libraries to make it easier to write menu extras and other app elements). I also like some of the ideas behind using MacRuby as a sort of GUI-REPL, and people should really check out Interactive MacRuby ( https://github.com/alloy/interactive-macruby). The more ideas we explore, the more we can begin to get a feel for what would make a good MacRuby library. Eventually, I think we can begin to understand what direction we want MacRuby to go in. I think it is important to remember that many people were using Ruby for CGI apps before Rails came along, and many more were using Rails on personal side projects for years before any companies took it seriously. All that said, I think perhaps the best thing that the core team can do right now is to better facilitate discussions. The website needs some work. Trac is not the best bug tracker in the world. But the list is not doing too bad, and I try to keep an eye on our IRC channel. I know waiting is the hardest part, but I do think that 2012 is going to be a banner year for MacRuby. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Document based application template
I cannot say or certain why the problem occurred. I did further investigation on another computer and the problem did not repeat with the same same code. I then rebooted the first computer and the problem went did not occur. I apologize for not posted that the problem was corrected to the list. In all honesty, when I never received any responses, I was not sure the email ever made it on the list. As I am still running Snow Leopard on all of my systems, I continue to run XCode 4.0.2. I have had no further problems as described below. The advice to upgrade is well-meant but not possible with the current version of the OS that is running. I am planning to begin the upgrade process in the break between Christmas and New Years. Andy Stechishin On Thu, Dec 22, 2011 at 1:59 AM, Maik Kempe wrote: > Hi all, > > I know, it is a lame advice but maybe you should upgrade Xcode / MacRuby. > Then you can create a Document based application via the wizard which works > like charm for me. > > If everything is not working, drop me a line and i can send you the generated > skeleton from the wizard. > > On Dec 22, 2011, at 8:46 AM, Min Soo Kim wrote: > >> Hi Andy Stechishin, >> >> I am have the same problem as you. >> It seems that no one is answering to your question. >> Have you find a what the problems was? >> >> Thank you in advance >> >> Min Soo Kim >> >> >> On Jul 23, 2011, at 12:46 PM, Andy Stechishin wrote: >> >>> I am trying to make a Document based MacRuby application. I create the >>> new project in Xcode4 (4.0.2) and immediately select build and run. >>> The application starts but there is no "Untitled" window and the >>> File->New and File->Open menu options are greyed out. Following the >>> same sequence of actions except choosing an Objective-C based >>> application, the "Untitled" Window appears and the menu options are >>> active. I have compared the project contents, the xib files (including >>> File Owners and First Responders) and linked frameworks and can find >>> no difference that would explain the different operation. It would >>> seem that there is some problem with NSDocumentController in the >>> MacRuby version. It is either not there or has been added properly to >>> the responder chain. >>> >>> Am I missing something? Or is this a defect? Has anyone else >>> encountered this and found a work around? >>> >>> Andy Stechishin >>> ___ >>> MacRuby-devel mailing list >>> [email protected] >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > Maik Kempe > Br∑αkíηg £ímíτs | impossible = POSSIBLE > > -- > > Br∑αkíηg £ímíτs > [email protected] > breaking-limits.com > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby scripting bridge speed
On Friday, December 16, 2011 at 10:17 AM, Stephen Horne wrote:
> #!/usr/local/bin/macruby
> framework 'Foundation'
> framework 'ScriptingBridge'
>
> # I followed Matt's instructions for making the bridge support file, but I
> wasn't sure where it needs to go, so I did this for a quick fix.
> load_bridge_support_file '/Users/fatboy/inDesign.bridgesupport'
>
> appurl = NSURL.fileURLWithPath("/Applications/Adobe Indesign CS5/Adobe
> InDesign CS5.app")
> @id = SBApplication.applicationWithURL(appurl)
> doc = @id.activeDocument
>
> puts doc.name (http://doc.name)
>
> pgph = doc.allParagraphStyles
>
> pgph.each do |style|
> puts "#{style.name (http://style.name)}"
> puts style.properties["appliedFont"].name
> end
>
>
>
> This code works, but it takes 15+ seconds to set up the link to InDesign
> (similar stuff with safari takes about 1 second, and in applescript or
> rb-appscript it takes about a tenth of a second for either InDesign or
> safari).
>
> I also tried
> SBApplication.applicationWithBundleIdentifier("com.adobe.indesign"), and this
> was just the same.
>
> Is there something I am missing here?
I am afraid I don't have a copy of InDesign, so I cannot test your specific
situation. However, it would be interesting to know what part of your script is
slow. Specifically, I would be interested in seeing some benchmarking to
indicate whether your script is wasting more time on the
"load_bridge_support_file" line or the "SBApplication.applicationWithURL" line.
(I suppose calls through to InDesign could be the bottle neck as well, but that
would be rather unexpected I should think.)
You can probably start off with Ruby's Benchmark library (with some decent
documentation here: http://rubydoc.info/stdlib/benchmark/frames , though
honestly you only really need "Benchmark.measure"). From there it might be
interesting to look at other profiling results, but best to start simple.
- Josh
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Speed
2011/12/21 François Boone
> Hi Josh,
>
> In macirb, I use:
> load "actionAffiche.rb"
> 461 queries, real time: 11.578257s
>
> In Xcode:
> I use rubygems and mysql macgems
> I have one Button and one table with two columns: when I press the button,
> the function actionAffiche is running. I think that it's a complete minimal
> example.
> 461 queries, real time: 64.244236s
> Apart MainMenu.xib, all my code is in AppDelegate.rb. I put this file at
> the end of this mail (Is there a better way?)
>
> I don't have control on mysql tables since they come from another software.
>
> I am a novice, then you can criticize my code :)
>
Not at all. Your code is quite ok. The only comments I would have is that
you should avoid using globals (variables starting with '$') whenever
possible, and your indenting is slightly non-traditional. Typically, in a
begin/rescue/ensure/end, all of the keywords are indented to the same level
so that it is easier to identify each block of the statement.
>
> Regards,
> François
>
> ---
> #
> # AppDelegate.rb
> # ecm: exemple complet minimal
> #
> # Created by Boone François on 11-12-21.
> # Copyright 2011 Boone François. All rights reserved.
> #
>
> require 'rubygems'
> require 'mysql'
>
> $data = []
>
> class AppDelegate
>attr_accessor :window
>def applicationDidFinishLaunching(a_notification)
># Insert code here to initialize your application
>end
> end
>
> class CtrButton
>attr_writer :individu
>
>def awakeFromNib
>@individu.dataSource = self
>$ref_individu = @individu
>end
>
>def affiche(sender)
>actionAffiche
>end
>
>def numberOfRowsInTableView(individu)
>$data.size
>end
>
>def tableView(individu, objectValueForTableColumn:column, row:index)
>item = $data[index]
>case column.identifier
>when 'iden'
>item.iden
>when 'name'
>item.name
>end
>end
> end
>
> class Person
>attr_accessor :iden, :name
> end
>
> def actionAffiche
>
>t1 = Time.now
># Connexion au serveur MySQL
>begin
>dbh = Mysql.real_connect("localhost", "root", "", "Boone")
>## Récupération de la version du serveur et affichage
>puts "Version du serveur: " + dbh.get_server_info
>rescue Mysql::Error => e
>puts "Code d'erreur : #{e.errno}"
>puts "Message d'erreur : #{e.error}"
>puts "SQLSTATE d'erreur : #{e.sqlstate}" if
> e.respond_to?("sqlstate")
>ensure
>dbh.query("SET NAMES utf8")
>end
>
># Requête pour le nom de famille
>dbh.query("SET NAMES utf8")
>requete = "SELECT handle,surname FROM surname ORDER BY surname"
>reponse = dbh.query(requete)
>
>num_max = reponse.num_rows
>num = 1
>
># Pour chaque nom de famille, on cherche le prenom
>reponse.each_hash do |lastname|
>puts "Individu " + num.to_s + " sur " + num_max.to_s
>individu = Person.new
>individu.iden = lastname["handle"]
>individu.name = lastname["surname"]
># pour chaque nom, recherche du prenom à partir du handle.
>requete2 = "SELECT first_name,xcall FROM name WHERE handle ='" +
> lastname["handle"] + "'"
>reponse2 = dbh.query(requete2)
>reponse2.each_hash do |firstname|
>individu.name = individu.name + ", " + firstname["first_name"]
>if firstname["xcall"] != ""
>individu.name = individu.name + " (" + firstname["xcall"]
> + ")"
>end
>end
>
>$data.push(individu)
>num += 1
>end
>
># On ferme le lien mySQL
>dbh.close
>
>t2 = Time.now
>puts (t2-t1)
># Mise à jour de l'interface
>$ref_individu.reloadData
> end
So, two quick comments. First, you don't have to put all of this code into
AppDelegate.rb. Instead, you can make new files for each class, just as you
would with any other Ruby project. I did something like this for the talk I
gave to Boston.rb last week (slides here:
http://www.slideshare.net/jballanc/macruby-for-fun-and-profit). However,
that is unrelated to the slowness you are observing.
The source of your slowness is here:
$data.push(individu)
without seeing how you have everything hooked up, I can already guess that
this is causing updates to the UI after every query. Typically, updating a
UI is one of the slower things that you can do. An immediate speed up would
be to collect all of your query results into a temporary array, and then at
the end append them all to your $data object at once (but don't use a
global – probably better to make that a method in a class, and probably
better to write a separate class for your data source and UI controller –
but those changes aren't necessary for this fix).
- Josh
P.S. If you really want your UI to remain responsive while performing these
queries, then you will need to do the queries on a thread. Luckily, GCD
makes that relatively easy to do!
___
Re: [MacRuby-devel] Key-Value Compliance & valueForKey:
Hey Patrick, Just wanted to follow up on this…did you manage to resolve the issue? If not, could you make sure you log this bug with Trac (https://www.macruby.org/trac/report)? Thanks! - Josh On Thursday, November 17, 2011 at 3:44 PM, Patrick Rogers wrote: > Hi everyone, > > I'm trying to automatically generate the KVC-compliant methods for indexed > to-many relationships. > > Here's my current attempt, https://gist.github.com/1374142, which borrows > from hotcocoa's kvo_array (I couldn't get `kvo_array` to work and I wanted > something that could just automatically be backed by an Array). > > Anyways, countOf and objectInAtIndex: are both generated and work. > > However, when I try and use valueForKey() on my generated keys, MacRuby > crashes with: > > > unknown: [BUG] unknown Objective-C immediate: 0x1 (nil) > > > > MacRuby 0.11 (ruby 1.9.2) [universal-darwin10.0, x86_64] > > > > [1]26123 abort macruby kvo_array.rb > > It is my understanding this should return an array based on my countOf > and objectInAtIndex: methods. > > On the other hand, when I use the manually defined methods, valueForKey(...) > works as expected. > > Is there an issue with my code/approach or is this a MacRuby bug? > > Thanks, > Patrick > ___ > MacRuby-devel mailing list > [email protected] (mailto:[email protected]) > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby scripting bridge speed
On 16 Dec 2011, at 15:17, Stephen Horne wrote:
> This code works, but it takes 15+ seconds to set up the link to InDesign
> (similar stuff with safari takes about 1 second, and in applescript or
> rb-appscript it takes about a tenth of a second for either InDesign or
> safari).
>
> I also tried
> SBApplication.applicationWithBundleIdentifier("com.adobe.indesign"), and this
> was just the same.
I can confirm the same problem with setting up a scripting bridge link to
InDesign. In my experience rb-appscript is far superior to scripting bridge,
it's a shame it can no longer be developed. Explained here:
http://appscript.sourceforge.net/status.html
I've never attempted to use macruby-appscript, but it might be worth trying?
https://github.com/dnagir/appscript/tree/master/macruby-appscript/trunk
Al
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby challenge
I'm glad things are now working as expected. My young cousins should be entertained by it during the Xmas holiday – I'll have to look for some extra disguises; Samuel L. Jackson would certainly be good, though Peppa Pig might be more appropriate. Thanks to Matt, Pavlos and Sean – definitely a group effort. Al On 21 Dec 2011, at 18:13, Jordan K. Hubbard wrote: > Also confirmed to work on my MacBook Air! > > Nice Job, Alan! A great example of what can be done (in very few lines at > that) in MacRuby! > > Now I'm off to find the right hairpiece and mustache to turn this into a > Samuel L. Jackson-ificator. ;-) > > - Jordan ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] A Future for MacRuby
Hi Jordan, Are you aware that HotCocoa is being actively developed again? https://github.com/HotCocoa/hotcocoa/blob/master/History.markdown There is a good overview of contributions over time here: https://github.com/HotCocoa/hotcocoa/graphs/impact Cheers, Isaac On Wed, Dec 21, 2011 at 8:56 PM, Jordan K. Hubbard wrote: > > On Dec 21, 2011, at 12:43 AM, David Frantz wrote: > > As to nibs well the whole thing is just very obtuse and frustrating to me. > Mind you my background is not the same as many here, being focused on > industrial automation, but if find the use of nibs and Interface builder to > be very taxing and not very object Oriented. MacRuby would likely generate > a lot more interest if they moved away from the interface builder approach > to GUI development. I know this will result in many arrows coming my way, > but really folks lets be objective here IB is a very strange departure from > most GUI development systems. > > > That was essentially the goal of the HotCocoa project, but it seems that > very few folks shared your concerns or your desire for XIB-less UI > development since outside contributions (once Rich moved on to other things) > have been extremely minimal. > > - Jordan > > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] A Future for MacRuby
All, I cannot separate the stakeholders (and their issues) from the roadmap. MacRuby will go where people who care to push want it to go. Barring getting a job where I am paid to push MacRuby in a certain direction, I will be at best a small addition to the overall effort. Given that, I would like to feel that 1) I am not pushing in a direction that will be nullified by more powerful stakeholders or 2) an indifferent universe will not cause any effort I put forth for MacRuby to be spilled out upon the sands. Apple is the 800-pound gorilla in the room and can certainly cause either outcome to happen, whether by malice or indifference. I don't need a blessing but a gesture would help a lot. It is one thing to get paid to write shelf-ware, and another to spend your spare time doing it! So, to avoid the first problem I would like Apple to give some guidance to the community as to what it sees it's interest is in MacRuby. I know I am dreaming and this is totally against the Apple way. To avoid the second problem I would like to see some indication that Apple plans to move forward on including MacRuby in it's offerings as a first-class citizen on all platforms. Again, I am dreaming to think that could happen. This is all in response to the call for participation in the project. There aren't many people who have the skill set to work on MacRuby and the willingness to work on a project with such little transparency from the main stakeholder. So please don't be unrealistic about what support MacRuby is likely to garner. My point about iOS was that MacRuby depends on garbage collection which is not currently included in iOS, and it would take a big engineering effort to get a version of MacRuby that doesn't require garbage collection. If you have a spare man-year to dedicate to making a version of MacRuby that works without garbage collection, more power to you! But are you going to do that with the chance that Apple will add garbage collection support to iOS at any point? I won't. I don't have a spare man-year and if I did I would spend it on a less risky venture. I was talking about established bugs in the Trac database when I mentioned Fibers(https://www.macruby.org/trac/ticket/253) and encodings(Net:SSH:https://www.macruby.org/trac/ticket/530). There are gems that cannot run under MacRuby because these features are not supported. The code is already written, make it run! I have been looking into some of the more esoteric problems with the current implementation of MacRuby and am hesitant to put too much effort into it because of the "integrate into Objective-C" focus of the project. The changes to get some of the problems fixed with the problematic gems may or may not cause serious performance problems for all of MacRuby, or integration problems with Objective-C frameworks like cocoa. I don't see Apple being supportive of these kinds of changes. Again, this is where the stakeholders and the direction are inextricably entwined. I wouldn't be writing all of this if I didn't see a lot of potential for MacRuby. I want to see it succeed and be a blazingly fast ruby implementation. The better it supports all of the gems, the better it will support any arbitrary ruby code I write. I want MacRuby to succeed and be available. But, I accept that the only thing I may get out of working on MacRuby is the work. Jeff Hemmelgarn p.s. I think MacRuby should be the slam-dunk ruby for Apple devices. That requires being the best ruby on the Mac and iOS devices. cocoa integration goes a log way to that end, but compatibility, speed and usability are also important. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby scripting bridge speed
If it is ScriptingBridge that is slowing things down, then this sounds like
perfect fodder for a bug report to Apple.
- Josh
On Thursday, December 22, 2011 at 12:15 PM, Alan Skipp wrote:
> On 16 Dec 2011, at 15:17, Stephen Horne wrote:
>
> > This code works, but it takes 15+ seconds to set up the link to InDesign
> > (similar stuff with safari takes about 1 second, and in applescript or
> > rb-appscript it takes about a tenth of a second for either InDesign or
> > safari).
> >
> > I also tried
> > SBApplication.applicationWithBundleIdentifier("com.adobe.indesign"), and
> > this was just the same.
> I can confirm the same problem with setting up a scripting bridge link to
> InDesign. In my experience rb-appscript is far superior to scripting bridge,
> it's a shame it can no longer be developed. Explained here:
>
> http://appscript.sourceforge.net/status.html
>
> I've never attempted to use macruby-appscript, but it might be worth trying?
>
> https://github.com/dnagir/appscript/tree/master/macruby-appscript/trunk
>
> Al
>
> ___
> MacRuby-devel mailing list
> [email protected] (mailto:[email protected])
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
