t’s trivial to get a similar result if needed.
* in conclusion, I don’t see how exposing more of the internal implementation
as controllable options *reduces* the need to understand the internals
—Matt Jones
--
You received this message because you are subscribed to the Google Groups "Ruby
cets:
https://github.com/rubyworks/facets/blob/master/lib/core/facets/proc/compose.rb
I haven’t tried it, but in principle this should work if the operator
precedence goes correctly:
orders.map(&:order_options * &:item * &:title)
—Matt Jones
--
You received this message beca
` method.
This could be too late to see things like dirty tracking, though - you may need
to start searching up the call stack from `_update_record`.
—Matt Jones
> If anyone could give me any advice on where might work to hook into AR to
> change generated SQL for 'update', I would appr
HTTP2 Early Hints are shipping in 5.2.0, which is currently in RC.
More details: http://eileencodes.com/posts/http2-early-hints/
<http://eileencodes.com/posts/http2-early-hints/>
—Matt Jones
> On Feb 11, 2018, at 5:54 AM, utilum <oz.shel...@gmail.com> wrote:
>
> What is
`app/models/admin/admin.rb`? AFAIK that’s not going to work with the
existing autoloader - it won’t look there by default, and it would expect a
file located there to define a class or module named `Admin::Admin` if it did.
—Matt Jones
--
You received this message because you are subscrib
9a395/lib/rspec/rails/adapters.rb#L22>
I’ll reiterate Rafael’s point from earlier in the thread: why is removing this
dependency important?
—Matt Jones
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this
ut something went wrong” (RecordNotSaved, RecordNotDestroyed,
StaleObjectError, UnknownAttributeError) than the situations that raise
StatementInvalid.
—Matt Jones
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubs
generated: people who understand the risks end up having to do a slight amount
of additional ceremony, and people who don’t understand the risks copy-paste
the incantation to “make it work”.
—Matt Jones
> I do think it would be strange for bcc to be the default, though. The only
> alterna
ific visitors in Arel.
I suspect the most difficult work for a change like this would be coordinating
& messaging the update - it would need to be announced quite prominently, since
the change will result in queries returning different results while still
succeeding.
—Matt Jones
--
You received
%>
<% else %>
Content for false
<% end %>
IMO, `link_to_if` and `link_to_unless` are intended to capture a common
pattern that would otherwise lead to repeated strings / code. If you need a
behavior that's well outside of that pattern, just write ERB / helpers /
etc.
--Matt Jones
same
> effect of :
> publications = books.published.map(&:publication)
>
> I'd *like* to write something similar to:
> has_many :publications, through: { :books => :published }
>
>
>
I'd handle this with a specifically-named association (in `Author`):
has_many :published_books,
for that uncommon case at a runtime cost for the common one.
--Matt Jones
On Thu, Oct 1, 2015 at 4:25 AM, Xavier Noria <f...@hashref.com> wrote:
> The only time I've seen one connection per thread being an issue was in
> one app that ran many processes and it started to reach the connec
manipulate these variables, as the connection used in the first
statement may not match the one used in the second. More amusing /
worrisome, somebody ELSE gets a connection with an altered SQL_MODE...
--Matt Jones
--
You received this message because you are subscribed to the Google Groups
s:
http://guides.rubyonrails.org/association_basics.html#polymorphic-associations
My guess is that that functionality will allow you to avoid the `table_name`
swapping that’s tripping up the code above.
But also note that this list is for development of the Rails framework, not for
debugging indi
equire conversion (coalwater’s modification
from your Gist) the object returned from `||=` DOES match, and Waldo is found.
Not sure if there’s a fix for this - the converting-on-[]= behavior is
something many applications are likely to depend on, and the behavior of
assignment operator
with trigger-supplied data
(calling `reload` after saving) won't work for. :)
--Matt Jones
Dne pátek 21. srpna 2015 17:26:49 UTC+2 masa331 napsal(a):
Hi guys,
this is code from ActiveRecord::Persistance:
def _create_record(attribute_names = self.attribute_names)
attributes_values
the desired behavior more easily
configurable. What do you think?
+1 to making it configurable.
—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
this:
https://gist.github.com/al2o3cr/3e1c492af329add23f30
--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
suggest revoking that permission from the user your application
connects to the database as.
—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
://stackoverflow.com/questions/14616453/image-placeholder-fallback-for-html5-video
Setting a placeholder won’t help those browsers, since they don’t handle the
tag at all.
—Matt Jones
On Sunday, March 29, 2015 at 6:30:21 PM UTC-3, Aaron Cordovez wrote:
It seems like there is no way to provide a fallback
in a variant (https://github.com/r-lyeh/base91) which uses
a different set of characters.
—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
that a particular test uses transactions internally
(after_commit hooks, etc) and therefore *shouldn’t* be wrapped with a
transaction. You’d specify this by saying `uses_transaction
:name_of_test_that_uses_transactions` in your test case.
—Matt Jones
--
You received this message because you
and the related issue:
https://github.com/rails/rails/issues/15792
—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
this much, again,
submit a PR for discussion. You’ll need to explain why you want to make a
breaking change in every app that uses a function that hasn’t changed in years,
and you’ll need to provide a patch to deprecate the old names in the next 4.x
series release.
—Matt Jones
for subclasses from the direct descendant of AR::Base.
—Matt Jones
On Feb 3, 2015, at 4:52 AM, Matthew Dunbar m...@mattdsworld.com wrote:
Suggesting that we can auto generate the prefix based on the module name,
rather than setting it with the existing method. Then eventually this feels
like
worth
keeping in source control. If writing a db/seeds.rb file is too complicated
(maybe you’re importing large datasets from elsewhere), I’d recommend things
like YamlDb to make repeatable seed data. Even `mysqldump sample_data.sql` is
a start…
—Matt Jones
--
You received this message because
://explainextended.com/2009/05/21/choosing-column-order/ (YMMV, I haven’t
performed this experiment myself)
If this is added, it should be something users can switch off.
—Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To unsubscribe from
/blob/7a519429600715f7140f3dcda5efe18c73976996/lib/composite_primary_keys/base.rb#L126
—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
because it’s not promising via
naming things that it can’t actually deliver.
—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
filtering aspect clearer.
—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
` is the
same as your `find_in_relation`…
records = Model.where(...)
records.where(attribute1: attribute1, attribute2: attribute2, attribute3, …)
Can you explain further what `find_in_relation` is intended to do differently?
—Matt Jones
--
You received this message because you are subscribed
* validations is “run every time the record is
saved”, so I don’t think it would make sense for one of them to be different
out-of-the-box.
—Matt Jones
signature.asc
Description: Message signed with OpenPGP using GPGMail
has_association? would be useful in your code?
—Matt Jones
signature.asc
Description: Message signed with OpenPGP using GPGMail
` for an input tag do the right thing?
—Matt Jones
signature.asc
Description: Message signed with OpenPGP using GPGMail
, for instance, is usually NOT 0.0 like you’d expect…
—Matt Jones
signature.asc
Description: Message signed with OpenPGP using GPGMail
are almost always solving important security issues.
—Matt Jones
On Sep 3, 2014, at 10:12 AM, skt stibre...@gmail.com wrote:
Thanks Ryan.
I have a User model (using Devise/Omniauth) and I call the assign_attributes
on an instance of User.
Part of what I am wondering is why isn't
`: return a new Hash with only the given keys.
—Matt Jones
signature.asc
Description: Message signed with OpenPGP using GPGMail
/
that seem likely to further complicate the situation.
—Matt Jones
signature.asc
Description: Message signed with OpenPGP using GPGMail
no decimal
formats when needed.
This appears to be possible on an application-wide basis as of 4.1.0:
https://github.com/rails/rails/commit/c0965004486f2ea5a9656ba718a3377c9614f97d
—Matt Jones
signature.asc
Description: Message signed with OpenPGP using GPGMail
, but there are reasons that
somebody might want to do it. We can’t save people from doing
silly-but-potentially-valid things.
—Matt Jones
signature.asc
Description: Message signed with OpenPGP using GPGMail
Fiorini) mentioned the config folder
potentially being unnecessary. That would tend to involve initializers. :)
—Matt Jones
On Wednesday, June 11, 2014 6:42:52 PM UTC-4, Matt jones wrote:
On Jun 11, 2014, at 3:13 PM, Pier-Olivier Thibault pot...@gmail.com wrote:
On Wednesday, June 11, 2014
of the “set up the paths but don’t load the
whole env” reasoning for boot.rb being separate from environment.rb (mentioned
down-thread by Ryan Bigg). Is this still something useful? If it isn’t, how
will (for instance) Rake tasks that don’t depend on :environment be switched
over?
—Matt JOnes
On Jun 11, 2014, at 3:13 PM, Pier-Olivier Thibault poth...@gmail.com wrote:
On Wednesday, June 11, 2014 3:57:59 PM UTC-4, Matt jones wrote:
On Jun 11, 2014, at 12:32 PM, Joe Fiorini j...@joefiorini.com wrote:
I actually played with simplifying the structure some time ago, although
I’ve had to resort to some pretty weird cookie stuff when passing data between
a Rails app and non-Rails applications. The session is handy, but parsing it
anywhere but in Rails is difficult and *updating* it outside of Rails is more
difficult.
—Matt Jones
On May 17, 2014, at 9:12 AM, Gabriel
` and `eager_load` would still be needed to specify the
correct behavior in those cases.
It’s definitely worth discussing, but it’s going to (IMO) face a pretty steep
climb to success.
—Matt Jones
signature.asc
Description: Message signed with OpenPGP using GPGMail
confusing that I’m pretty sure your expanded example is
incorrect; `Foo` is unlikely to have a column named `foo_id`…
—Matt Jones
signature.asc
Description: Message signed with OpenPGP using GPGMail
params.require :two
params.require :three
my_params = params.permit :one, :two, :three, :four
Does this actually work? I swear I’ve gotten into trouble with calling `permit`
on the top-level params hash, since there’s other stuff (:controller, :action,
:format, etc) in there…
—Matt Jones
tricks)
* SQLite3: supported if enabled at compile time
* MySQL: supported
* SQL Server: not supported (but maybe with a TOP subquery?)
—Matt Jones
signature.asc
Description: Message signed with OpenPGP using GPGMail
the specified attribute, not other
ones. Thus it is violating POLA
```
This behavior was exactly why update_attribute was (briefly) deprecated in
3.2.7:
https://groups.google.com/forum/?hl=enfromgroups#!topic/rubyonrails-core/BWPUTK7WvYA
Not sure how it got un-deprecated...
--Matt Jones
--
You
are generally valid SQL
but return incorrect results.
I'd also appreciate any insight people can put on #14155, but that's lower
priority since it's been broken in the same fashion since 3.x.
Thanks,
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
be derived from
the class names but can also be declared, when you have a legacy db.
The configuration is one level higher, when you pick a cache_store:
config.cache_store = :file_store, /path/to/cache/directory
(from the caching guide)
--Matt Jones
Am Dienstag, 11. Februar 2014 19:52:15 UTC+1
.
—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
is to chain together
Marshal.dump and Marshal.load, but that’s almost *got* to be terrible for
performance.
—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
present?
--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
you guys think?
I think that if you're putting boolean columns in your DB that don't default to
either true or false you are doing it wrong. If you really want yes / no /
didn't answer semantics, use a type that represents that.
--Matt Jones
--
You received this message because you
is that one of them successfully generates + calls the requested
method while the other fails with NoMethodError. :(
The fix is (as far as I can tell) pretty straightforward, so this would be
great to get into 4.0.1.
--Matt Jones
--
You received this message because you are subscribed to the Google
: the user is utterly pwned seems a bit hyperbolic.
Drink your SSL + Secure cookies, kids!
--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
, however, if it involves any creation,
deletion or modification, it will connect to the master one.
That's pretty much exactly what replication in octupus does:
https://github.com/tchandy/octopus/wiki/replication
:)
--Matt Jones
--
You received this message because you are subscribed
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
-01-01 (or so...)
- SQLite doesn't exactly support a native DATETIME type, but it stores the
values as strings. DATETIME is preferred (best I can tell) over TIMESTAMP
because the SQLite gem parses TIMESTAMP columns into Time objects while
DATETIMEs become DateTime objects.
--Matt Jones
--
You
really expensive if you have a lot of rows on the other end of
the HABTM, since you cache the complete list of IDs in memory
--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
. :)
Snark aside, I think adding too many bells-and-whistles to `delegate` is not
the best idea. If you really want custom behavior, why not make it clearer and
just write the methods?
At a minimum, code-as-string is kinda gross.
--Matt Jones
--
You received this message because you
column (which you should be doing
anyways :) ) and have a nice life.
--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
dispatch is pretty hair-raising.
--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
There are two existing issues related to this:
https://github.com/rails/rails/issues/950
https://github.com/rails/rails/issues/7402
The code in #7402 may be helpful in your particular situation.
--Matt Jones
On Apr 8, 2013, at 2:21 AM, Alfonso Uceda wrote:
Ok thank you, I'm going to publish
(a string or
variable), the second argument can also be a bunch of params for url_for:
link_to 'thingy', :controller = 'wat', :action = 'huh', :protocol = 'wtf'
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To unsubscribe from
On Mar 15, 2013, at 2:39 PM, Michael Grohn wrote:
@Matt jones
I'd guess that it's because while the body is typically simple (a string or
variable), the second argument can also be a bunch of params for url_for:
link_to 'thingy', :controller = 'wat', :action = 'huh', :protocol
. You absolutely need a way to run an
actual query when you want the latest results. to_a cannot be relied upon to
do this in all cases.
p.tasks(true) will *always* reload the association. I haven't seen the
equivalent for relations, though.
--Matt Jones
--
You received this message because
the ActiveModel APIs.
--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
, wouldn't this work nearly as well:
def incomplete_submissions
submissions.to_a.count(:incomplete?)
end
In short, if you want the Enumerable behavior, just ask for it...
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group
to race conditions is needed.
I believe the suggested solution in this case is to use optimistic locking (via
a lock_version column) and then handle collisions manually.
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group
, selecting Rspec would produce a paragraph
about how to run the specs.
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send
, Date.current)
end
end
This still has the issue identified by G. Sobrinho, however, where explicitly
setting an attribute to nil doesn't work quite right.
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post
, and am curious if it would be better to split the bugs out as
individual issues (happens sooner) or fix them in a bigger patch (takes longer).
Thanks,
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send
magic...
render partial: magic_helper
end
Why is this wrong?
What's it failing to do? I've used this pattern frequently for partials that
need some extra argument preprocessing and haven't encountered problems.
--Matt Jones
--
You received this message because you are subscribed to the Google
correctly for anything but fairly similar
queries; joins, selects, etc all go out the window.
--Matt jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe
.
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more
On Jul 24, 2012, at 5:42 PM, Jon Leighton wrote:
On 24/07/12 21:29, Matt Jones wrote:
Nope, that's not exactly what I observed; I'll try again. That code *does*
call the create correctly, if there are no users with the correct
first_name. The confusing part to me was that it wasn't
implements the behavior I was expecting in their
first_or_create method:
https://github.com/datamapper/dm-core/blob/master/lib/dm-core/model.rb#L448
Thoughts?
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group
in 4.1 - see
active_record_deprecated_finders for details), it's worth either matching the
old behavior or clearly documenting the difference to avoid confused upgraders.
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post
, but not a bug.
Definitely worth an update to the documentation, though.
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send
- [:created_at, :updated_at]
Note that this may die in exciting ways if you put it in a model that hasn't
been created in the DB yet. (since columns looks at the table metadata)
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group
:
some_array.all?(:blank?)
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com
whitelisting.
Thus:
some_object.update_attribute(:foo, 'bar')
is NOT the same as:
some_object.update_attributes(foo: 'bar')
if foo isn't mass-assignable.
Not sure if it's terribly relevant, but worth mentioning.
--Matt Jones
--
You received this message because you are subscribed
://api.rubyonrails.org/classes/ActiveRecord/Persistence.html#method-i-touch
It now skips all the callbacks, etc entirely.
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core
[:project_id])
which turns attempts to access other's projects into 404s?
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group
:some_attribute, :unless = :some_other_attribute?
The no-? version doesn't do the right thing in many cases (since empty strings
evaluate to true), and using present? instead requires a Proc.
Not certain if this is a sufficient argument for the existence of the ? suffix,
but worth thinking about.
--Matt
to join
us over in the hobo-dev Google Group.
Thanks,
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email
Rails *without* a
similar generator, and then imagine the responses to a proposed generator that
would automatically create reasonably clean, idiomatic code that a new
developer could quickly see results from. Such a thing would likely be
popular...
--Matt Jones
--
You received this message
is that remove_root doesn't have any awareness of
the context in which it's operating - really, we should only be removing the
appropriately-named root element (if it exists).
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group
be great to get this patch in:
https://github.com/rails/rails/pull/4881
Does it count as a regression if ARes has *never* been able to parse the
default Responder's error messages?
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group
Created.
Is there a clean way to handle this? I like the idea of avoiding hackery like
including view helpers in models for as_json, but the response code changes
mean that I'm back to writing out respond_tos manually.
Thanks,
--Matt Jones
--
You received this message because you are subscribed
it
shouldn't break in any application that was working before.
https://github.com/rails/rails/pull/4881
Would appreciate any feedback - it would be nice for the framework to actually
work with its own API endpoints...
Thanks,
--Matt Jones
--
You received this message because you
orders.
I think this is a bug.
Here's a pull request to correct this behavior:
https://github.com/rails/rails/pull/4282
This also solves the original problem in a slightly different way - a
relation's order_values attribute is now always the ordering the final relation
will use.
--Matt Jones
On Dec 28, 2011, at 5:55 AM, Jon Leighton wrote:
On 27/12/11 14:32, Matt jones wrote:
https://github.com/rails/rails/pull/4082
I've commented on the PR.
Updated PR against master: https://github.com/rails/rails/pull/4216
On a related note, the current mechanism for handling 'reorder
not (as might be expected) sort the returned record by baz - the
reorder overrides all previous *and* subsequent orders.
Thanks,
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core
of append= is silently dropped on the floor.
Note that this will never be observed by users of the built-in ERB template
parser, since it automatically grabs @output_buffer in the Erubis postamble.
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
= DateTime.civil(2011,4,6,12,0,0)
d2 - d # returns Rational(1,2) - in other words, half a day since the docs
say Date objects are considered to have a time of midnight
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post
, this isn't the right place for this. In any case, I
suspect your issue is that Excel has spit out a UTF-16 file and you didn't tell
whatever's parsing it about that...
--Matt Jones
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post
, so I attached the patch file to
the ticket.
Since I'm still new on this, can someone please point me the right
procedure ? Should I have opened a new ticket ? Should I have changed
the tags associated to the ticket (I don't know how to do it) ?
Any help appreciated.
Ticket reopened.
--Matt
1 - 100 of 170 matches
Mail list logo
