Re: [Rails-core] not able to install rails getting an error "could not find javascript runtime"
I realized I could be more concrete. To achive the goals I named, we should: * Attempt to use or install a default javascript runtime. (I don't have the background to know if this is possible. It seems like an odd thing for the system to get hung up on, though.) * If that fails, arrange for a more helpful error message, a la db:migrate. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] not able to install rails getting an error "could not find javascript runtime"
The defaults already are reasonable, in my opinion. I wouldn't mind hearing a concrete proposal to improve them, though. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] not able to install rails getting an error "could not find javascript runtime"
On Wednesday, September 18, 2013 10:03:09 AM UTC-7, Steve Klabnik wrote: > The defaults already are reasonable, in my opinion. I wouldn't mind > hearing a concrete proposal to improve them, though. Working outside-in, I'd say our goals should be: * A person can install and run a new rails app without "error" messages. * If an "error" message must be shown, then it should clearly describe (1) the source of the error, and (2) what's needed to remedy it. So IMO the current set up isn't reasonable because (1) the behavior is designed-in (I.e., we've designed Rails to fail) yet (2) we're telling the user they've made an error. Also, (3) the error message is really just a fall-through which doesn't give a high level semantic understanding of what's going on. Contrast this with the more helpful message of rake's checking for db:migrations which haven't been run. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] Rails Guides Idea: Links to relevant API pages
On Wed, Sep 18, 2013 at 6:30 PM, Robb Shecter wrote: I'm totally up for working on this. I'll look at the Guides source and > learn how they're compiled. I can imagine a new CSS Guides style is the > minimum that'd be needed: something to set up the API link for deeper > information. And in the best case, this could be a simple database: a > many-to-many relationship between topic areas and API pages. > Well, my idea is much more simple. I envision links intermixed with the content, or a section at the bottom "Related API". nothing more fancy than that. Let's see it off-list if you like. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] Inconsistent(?) datetime and timestamp handling
> On 18 Sep 2013, at 00:57, Robb Shecter wrote: > > Matt jones wrote: >> >> The best type to use to store DateTime objects is database-dependent: > > So Ketan's finding seems to be correct, and this is something we should fix. > I.e., Rails' concept of timestamps should be database independent, just as > its concept of the primary key type is. (?) But that's exactly what's already happening. The different databases deal with date-time data in fundamentally different ways under the hood, and Rails can't change that. But what it can do (and what is happening in the code we're looking at here) is talk to each database using its own specific vocabulary about date-time data, and then translate that to a single Ruby representation of DateTime that is the same regardless of which database is being used. The fact that the code in Rails uses different vocabulary to talk to different databases isn't a problem to be fixed. Rather, it's the only way to talk to those different databases, and is the right thing to be doing. Now, if we were discussing a specific bug where some DateTime columns actually *behave* differently to the programmer using Rails depending on which database is being used, then that would be something worth fixing. It would be evidence that the abstraction is broken in some way. But I haven't seen anything of that sort in this thread yet. (An example would be: Matt pointed out that the different databases have different acceptable ranges for their date-time data. This is probably a difference that does leak through to the Rails world. Is that a problem, and is it worth fixing it by sticking to a common range that can be stored in all the databases Rails supports?) Chris -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] Rails Guides Idea: Links to relevant API pages
I'm totally up for working on this. I'll look at the Guides source and learn how they're compiled. I can imagine a new CSS Guides style is the minimum that'd be needed: something to set up the API link for deeper information. And in the best case, this could be a simple database: a many-to-many relationship between topic areas and API pages. The db would be used by the Guides presentation code to add links at the end of each section as well as build an index of all listed API pages. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] Inconsistent(?) datetime and timestamp handling
On Sep 17, 2013, at 6:57 PM, Robb Shecter wrote: > Matt jones wrote: > > The best type to use to store DateTime objects is database-dependent: > > > So Ketan's finding seems to be correct, and this is something we should fix. > I.e., Rails' concept of timestamps should be database independent, just as > its concept of the primary key type is. (?) > I think you missed the point of my post: the choice of column MUST be database-dependent, since there's no type that's consistently available across all DB engines. Handling these differences in a way that's transparent to higher levels is one of ActiveRecord's responsibilities - for another example, note that boolean columns are stored in database-dependent ways: Mysql uses tinyint, SQLite uses a string with 't' or 'f', Postgres uses a native boolean type, etc. For what it's worth, not even the primary key type is consistent if you go a little farther afield. For instance, the built-in Mysql adapter uses an INTEGER(11) field for primary keys, but the oracle-enhanced adapter uses NUMBER(38) which doesn't even have the same available range. --Matt Jones -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] Rails Guides Idea: Links to relevant API pages
:heart: love this idea. On Wed, Sep 18, 2013 at 2:26 AM, Xavier Noria wrote: > This is a good proposal. > > We would need a helper to generate the subdomain depending on whether we > are generating edge or stable guides. > > Also, your idea is related to the new API home page that I have in mind. > The home page I envision has a similar purpose than your site, an index > with links to the main topics. The API home page is no longer the Rails > README to be able to do that. If you'd like to work on something like this > it would be awesome. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
